Free Software Foundation wil mobiel opensourcebesturingssysteem gaan ontwikkelen

De Free Software Foundation wil werken aan een opensourcebesturingssysteem voor telefoons. De stichting zegt te werken aan Librephone, een project dat een volledig mobiel platform vanaf de grond af op wil bouwen, al deelt de FSF daar nog geen details over.

De Free Software Foundation kondigde het project aan tijdens een bijeenkomst ter ere van het veertigjarig jubileum van de stichting. "Librephone is een nieuw initiatief van de FSF om volledige vrijheid naar mobiele apparaten te brengen", zegt uitvoerend directeur Zoë Kooyman. De FSF ziet 'veel potentieel om softwarevrijheid naar veel gebruikers over de hele wereld te brengen', omdat mobiele telefoons 'zo alomtegenwoordig zijn'.

De stichting geeft echter geen details over het project, waardoor het maar de vraag is hoe succesvol dat kan en gaat worden en wanneer er in de eerste plaats iets over te zien is. Het enige dat de stichting zegt, is dat de FSF samenwerkt met opensourceontwikkelaar Rob Savoye, die onder andere aan GNU werkt en een contributor is aan Debian en Red Hat.

Volgens It's Foss is het de bedoeling dat Librephone zowel de firmware als het besturingssysteem maakt volgens de principes van vrije software, maar daar is ook alles mee gezegd. Er bestaan naast Android en iOS al alternatieve mobiele besturingssystemen, zoals Ubuntu Touch of SailfishOS, maar geen daarvan heeft ooit echte populariteit weten te bereiken.

Reacties (126)

[aileron]

Een van de grotere redenen waarom de adoptie van Linux als desktop OS ontzettend moeizaam is, is omdat applicaties die veel mensen gebruiken niet beschikbaar zijn.

Ik voorzie helaas hetzelfde probleem met die soort OS'en. En Google heeft de bui van "Android apps compatible maken op andere OS'en" allang zien aankomen en dwingt nu ontwikkelaars met nieuwe "security" eisen deze exclusief werkbaar te maken voor Google Android met play services.
Elke ontwikkelaar zal een losse branch moeten ontwikkelen voor dit IS en je kunt nu al raden hoeveel ontwikkelaars dat gaan doen.

[Pyronick]

Een van de grotere redenen waarom de adoptie van Linux als desktop OS ontzettend moeizaam is, is omdat applicaties die veel mensen gebruiken niet beschikbaar zijn.

Dat klopt, maar dat beeld begint wel snel te kantelen.

Steeds meer applicaties verschuiven naar web-based platformen, waardoor de afhankelijkheid van specifieke OS-API’s afneemt. Daarnaast heeft Valve met Proton/Wine en hun focus op native Linux-ondersteuning (en zelfs macOS) een enorme katalysator gegeven aan compatibiliteit en professionalisering van de Linux desktop.

Ook aan de Linux-kant zelf is veel van de “technical debt” inmiddels ingehaald: de ooit niet-te-volgen dynamische ontwikkeling van de Linux-ABI is inmiddels gestabiliseerd, verouderde componenten zoals SysV, POSIX-legacy en X11 worden langzaam maar doordacht uitgefaseerd, en moderne toolkits als GTK4 en Qt6 hebben volwassen cross-platform-architecturen gekregen. Daarbovenop zijn met PipeWire, Wayland, Flatpak en containerisatie (podman, systemd-nspawn, en Docker) eindelijk langlopende achterstanden ingelopen die Linux jarenlang tegenhielden.

Kortom: de achterstand wordt niet langer groter, hij wordt eindelijk kleiner. En voor sommigen is het “jaar van de 'Linux' desktop” al een tijdje realiteit. Alleen zal het “jaar van de desktop” zelf m.i. nooit meer komen: die is waarschijnlijk inmiddels opgelost in het bredere ecosysteem van web, smartphones, smart-tv’s, narrowcasting, wearables en voice-assistants.

[kdekker]

Maar juist als het webbased is, heb ik geen zin in een losse app (die meestal meer rechten heeft en m.i. ook meer data weg kan slurpen).

[Pyronick]

Fair point! Zo zit ik er meestal ook in, tenzij het echt rete-traag is.

Aan de andere kant: wij zijn tweakers.

We weten, of hebben in elk geval een goed vermoeden, wat er onder de motorkap gebeurt, en zijn daardoor ook beter bewust van waar apps allemaal toegang toe hebben, ondanks het zogenaamd “betrouwbare” rechten­management van iOS en Android.

[schrikbeeld]

<quote>We weten, of hebben in elk geval een goed vermoeden, wat er onder de motorkap gebeurt, en zijn daardoor ook beter bewust van waar apps allemaal toegang toe hebben</quote>

Dat zal voor veel tweakers misschien gelden maar de bulk van de consumenten interesseert dat geen bal, zie de acceptatiebereidheid van apps als Signal.

[HijDieAllesWeet]

Wat bedoel je met de acceptatiebereidheid van Signal? Die app is toch juist wel goed?

[schrikbeeld]

De Signal app is prima maar WhatsApp is zo ingeburgerd en mensen zijn zo laks op hun privacy dat je vrijwel niemand meekrijgt.

[Melones]

gewoon totaal geen whatsapp hebben, laat hen maar door hoepels springen.

[bzuidgeest]

Denk maar niet dat een webbased app veel verschil maakt met een os specifieke.

De functionaliteit verandert niet een dus ook niet de rechten die daar voor nodig zijn. Enige verschil is dat ze die via een browser van een of andere soort verkrijgen.

Je Maps applicatie moet nog steeds weten waar je bent een waar je naar toe wil.

Web based is alleen maar meer bandbreedte nodeloos wegdoen. En een flinke portie van de wereld heeft nog data bundels. En lokaal draaiende app heeft veel voordelen dan.

Web based heeft ook security implicaties. En lokaal draaiende app kan van te voren veel makkelijker worden gescand dan een die alles uit de cloud haalt. Iets wat de ene dag veilig is, kan de volgende dag een door een hacker vervuild script ophalen.

[HSG]

Eens. Met de Linux distro die ik gebruik kan ik games opstarten van 20 jaar oud. Dat was eerder niet eens mogelijk en ze draaien prima.

[MrFax]

https://blog.hiler.eu/win32-the-only-stable-abi/

Dit is dan ook het probleem.

[dimdek]

Ik denk dat het grootste probleem is dat er geen geld en dus marketing achter zit. Daardoor worden winkels niet gemotiveerd om telefoons met alternatieven voor Android of iOS aan te bieden en is maar een heel klein deel van de conumenten op de hoogte van het bestaan van alternatieven. Om die reden zullen alleen zeer enthousiaste ontwikkelaars een ander platform omarmen.
Daarnaast is het bij mijn weten voor zowel Ubuntu als Sailfish altijd een probleem geweest dat ze geen gegevens van de chipproducenten krijgen (die leveren alleen aan Google). Daardoor moet voor bijvoorbeeld bluetooth alles eerste ge-reverse-engineerd worden en krijgen ze het nooit goed werkend. De reden dat ik ben gestopt met Ubuntu Touch en Sailfish is omdat Ubuntu niet werkte met mijn carkit en met Sailfish kan ik mijn smartwatch niet synchroniseren (hoewel zijn wel Android apps ondersteunen).

[rob12424]

Zeg dat niet te hard: veel mensen wisten niet eens dat bijvoorbeeld de Nokia N900 bestond. Marketing was er nauwelijks of summier. Tuurlijk had het de Naam Nokia. Maar toch werd dat een groot Suc6.

[dimdek]

Dat was in de tijd dat er nog niet al te veel machtsvertoon was. Vlak daarna heeft Google zich laten gelden en er alles aan gedaan om andere OSsen buiten spel te zetten door deals te maken met producenten (je mag onze sofware gebruiken, maar dan moet je wel...). Microsoft doet dat ook met Windows waardoor je nooit een Linux laptop in de winkel ziet liggen. Ik denk dus dat de markt in die tijd veel opener en naïver was en hoewel ik hoop dat het weer terugkomt ben ik bang dat Google altijd weer een strategie gaat toepassen om dat te voorkomen. Zoals ze nu ook verplicht gaan stellen dat apps bij installatie afkomstig moeten zijn van een bij Google geregistreerde ontwikkelaar omdat ze worden gedwongen alternatieve appstores toe te staan.

[GertMenkel]

Hoewel de identiteitsverificatie natuurlijk nogal stom is, is het aan de ontwikkelaar om te kiezen of ze wel of niet van Play Services afhankelijk willen zijn. En zelfs dan werken alternatieve implementaties en mocks meestal nog prima.

Sommige ontwikkelaars kiezen ervoor om niet te werken op niet-Google-telefoons door dingen als de Play Integrity API te gebruiken en telefoons die niet door Google ondertekende firmware draaien te blokkeren. Een door-Google-geverifieerde ontwikkelaar kan echter nog steeds apps maken voor Waydroid of een andere compitabiliteitslaag door gewoon niet te proberen om apparaten uit te sluiten.

In mijn ervaring is het grootste probleem met Android-apps op Linux dat de navigatie van touchscreen-aps nogal moeizaam gaat met muis en toetsenbord. Dat probleem heb ik ook met iPad-apps op macOS, al lijkt dat wel wat vloeiender te werken. Als je een Android-laag op een mobiel besturingssysteem zet, heb je dat probleem niet. Ik denk daarom ook dat dit idee niet zo dood is als pogingen om Android-apps naar Linux te werken.

Het probleem met mobiele besturingssystemen is in mijn ervaring vooral dat de (mainline) Linux-kernel in zijn standaardconfiguratie energie vreet als een malle, en dat ARM vanwege het gebrek aan BIOS/UEFI+ACPI veel hardwareconfiguratie op het moment van compileren moet worden voorbereid, waardoor dezelfde kernel niet werkt op verschillende apparaten. De beste gratis mobiele besturingssystemen maken dan ook gebruik van een wrapper om de open-source Android-kernel van de fabrikant te pakken en daar bovenop een eigen stack te draaien (zoals UBPorts dat doet). Alle gesloten drivers en rare kernel-tweaks werken daarom zolang je op die oude versie blijft hangen en de user interface kan met GPU-versnelling vloeiend werken.

Al met al denk ik dat met genoeg tijd en investering hier een prima systeem uit kan komen dat met een Android-laagje een goede start aan applicaties heeft. Ik denk alleen dat vanwege de complexiteit van het flashen van custom ROMs en het feit dat er maar weinig apparaten zijn waar dat systeem goed op draait. Een Sailfish 2.0: aardig besturingssysteem, maar te weinig interesse om grootschalige populariteit te behalen.

[Barryke]

Elke ontwikkelaar zal een losse branch moeten ontwikkelen voor dit IS en je kunt nu al raden hoeveel ontwikkelaars dat gaan doen.

Zodra dit OS webapplicaties ondersteunt, kan in principe alles werken.

Vrijwel elke app is slechts een native client die een webpagina had kunnen zijn. En heel vaak zelfs al een gerenderde webpagina is onder de motorkap.

[hachee]

@aileron Ik draai hier ook Sailfish OS op een Sony Experia(met Jolla/Sony HW licentie).
Deze bied de mogelijkheid android apk's te installeren (gebruik het zelf niet, native Sailfish OS apps volstaan hier).

De stichting zegt te werken aan Librephone, een project dat een volledig mobiel platform vanaf de grond af op wil bouwen, al deelt de FSF daar nog geen details over.

En vanaf de grond bedoelen ze ook Linux kernel? Of gaan ze dit eveneens baseren op het Mer-project(Zoals Sailfish OS) ?

[cdwave]

Een van de grotere redenen waarom de adoptie van Linux als desktop OS ontzettend moeizaam is, is omdat applicaties die veel mensen gebruiken niet beschikbaar zijn.

Ik denk voornamelijk gestuurd door afschrikkende verhalen van vroegah, toen er nog allerlei problemen met drivers en hardware ondersteuning waren. Ik heb overigens de indruk dat dat tegenwoordig omgekeerd is.

Voornamelijk gestuurd door roeptoeters die ergens een applicatie op weten te duikelen waar dan net geen alternatief voor is.

Dan is er nog een aantal mensen die niet vraagt om een goed beeldbewerkingsprogramma, maar die perse Adobe Photoshop willen draaien. Die zijn doorgaans prima te bedienen met wine, tegenwoordig kun je vrijwel alle Windows programma's onder Linux Wine draaien, ook zware 3D games draaien prima.

Mensen zoals ik en mijn 80+ jarige ouders die al jaren prima tevreden gebruikers van een Linux desktop zijn, die hoor je niet zoveel, afgezien van hier en daar een postje op een forum.

Ik voorzie helaas hetzelfde probleem met die soort OS'en. En Google heeft de bui van "Android apps compatible maken op andere OS'en" allang zien aankomen en dwingt nu ontwikkelaars met nieuwe "security" eisen deze exclusief werkbaar te maken voor Google Android met play services.
Elke ontwikkelaar zal een losse branch moeten ontwikkelen voor dit IS en je kunt nu al raden hoeveel ontwikkelaars dat gaan doen.

Ik denk dat de veel ontwikkelaars bouwen voor zowel Apple als Andoid, en een derde platform erbij heeft niet zo heel veel impact.

[henk717]

Android laat een gat in de markt vallen voor een echt open teletoon.... Met alle apps die je normaal kan draaien, app van de bank, etc.

En juist daar zit normaal het probleem en waarom ik geen toekomst zie in dit soort projecten. De teletoon maken is een ding en daar zijn al diverse open source projecten voor aanwezig. Maar vervolgens heb je geen apps en wil niemand het gebruiken.

Ben benieuwd of er ooit nog een speler zal zijn die dat weet te doorbreken.

[Pyronick]

Progressive web apps zijn _allang_ de oplossing. Alleen worden ze doelbewust tegengewerkt door de duopolisten (Google en Apple).

Tijd dat overheden hun eeuwenoude mededingingswetten eens gaan handhaven, in plaats van toekijken.

Dat geldt trouwens óók voor GPL-licenties, die al jaren massaal worden geschonden (m.b.t. misbruik van Linux).

[Reactie gewijzigd door Pyronick op 10 oktober 2025 16:50]

[Pyronick]

Met de dag verbaas ik me meer en meer over hoe mensen anti-monopoly wetgeving willen misbruiken, alleen maar om hun zin te krijgen.

Ironisch genoeg beschrijft die zin precies het omgekeerde van wat er aan de hand is. Een schoolvoorbeeld van projectie: een redenering waarbij men de ander verwijt wat men zelf doet.

1. Geen App stores meer die gebruikers veiligheid en zekerheid bieden.

Juist een gecentraliseerde app store ís misschien wel de grootste aanvalsvector die er bestaat. En als die dan ook nog in handen is van obscure Amerikaanse firma’s, wordt het alleen maar gevaarlijker én verdachter.

2. Allerlei functionaliteiten op de telefoon zullen niet langer werken zoals Bluetooth, NFC , FaceID of TouchID.

Hele stacks die door Apple en Google gebruikt worden, zijn grotendeels gebaseerd op bestaande open-source libraries en standaarden. De alternatieven bestaan al, als drivers of abstracties binnen o.a. Zephyr RTOS, de Linux-kernel of *BSD.

3. Progressieve Webapps zijn afhankelijk van een browser. Hallo Google Chromium.

De PWA-specificatie is nota bene door het W3C vastgesteld. Chromium is gebaseerd op Google’s “open-source” Blink, dat weer gebaseerd is op Apple’s “open-source” WebKit, wat oorspronkelijk voortkomt uit KDE’s open-source KHTML. Open source is en was dus letterlijk de fundering.

4. De performance van Progressive Webapps is vaak niet al te best, niet te vergelijken met natieve apps.

De lagere performance van PWA’s is deels by design, deels door bewust nalatig gedrag van Big Tech, deels omdat sandboxing nu eenmaal een veiligheidsmaatregel ís.

Antimonopoliewetgeving “misbruiken” lijkt me een bizarre framing. Consumenten moeten juist beschermd worden, niet alleen tegen bedrijven, maar ook tegen machtigere of (invloed)rijker consumenten, denk bijv. aan de "blue bubble"-brigade uit de VS. Wat velen “realistisch” noemen, is eerder elitair consumentengedrag, en precies dát is wat een goed functionerende rechtstaat tegen hoort te beschermen.

Zoals de democratie zonder rechtstaat de tirannie van de meerderheid is, zo is de "vrije" markt zonder rechtstaat de tirannie van de welgestelden.

[Pyronick]

Apple en Google obscure firma’s noemen zegt me al genoeg.

Dat zegt meer over jouw verwachtingen van deze multinationals dan over mijn observatie.

Met obscuur bedoel ik niet ‘kwaadaardig’, maar ‘niet transparant’. En op dát vlak zijn Apple en Google inderdaad bijzonder en heel selectief schimmig.

Al is het maar omdat bijna alles open source is, behalve precies daar waar je wilt weten wat er met je data gebeurt.

Ik hoef niet de broncode van de rekenmachine te zien, maar wél wat er in die niet-gedocumenteerde, versleutelde string zit die elke vijf minuten naar hun servers wordt gestuurd.

Browser apps ongecontroleerd toegang geven tot je gehele telefoon, wat kan er mis gaan?

Dat is een glijdende schaal-drogreden: Niemand pleit namelijk voor “ongecontroleerde toegang tot je hele telefoon”.

Daar bestaan juist permission pickers en capability-based APIs voor, mechanismen die al jaren in Android (en dankzij GNU) en Linux maar ook in iOS bestaan.

Het punt is keuzevrijheid: dat je zelf kunt bepalen welke distributiekanalen, welke permissies en welke apps je gebruikt (of juist niet, wat ook steeds vaker opgedrongen wordt).

App stores bieden gewoon veiligheid doordat ze apps scannen, veiligheid omdat ze de identiteit van de appbouwer vaststellen voordat de app gepubliceerd wordt.

Dat klinkt mooi, maar de praktijk is minder rooskleurig.

De App Store is zelf een centrale aanvalsvector. Denk aan XcodeGhost, waarbij duizenden goedgekeurde iOS-apps besmet bleken, ondanks Apple’s “veiligheidsscan”.

Centralisatie blijkt geen garantie voor veiligheid, maar steeds vaker het tegenovergestelde.

Native apps verbieden ten faveure van progressieve webapps heeft niets met anti-monopoly wetgeving te maken. Dat is wat ik misbruiken noem.

Maar dat is een stroman drogreden: niemand heeft ooit gezegd dat native apps verboden moeten worden.

Het gaat erom dat PWA’s niet kunstmatig worden beperkt of tegengewerkt.

Een progressieve webapp draait in de browser. De Chromium browser weet dus ten alle tijden wat de gebruiker doet met zijn telefoon. Want er zijn geen apps meer buiten de browser om.

Maar dat is weer een glijdende schaal:

Alsof er “geen apps meer buiten de browser” zouden bestaan.

Bovendien ben ik (en voorlopig andere Android gebruikers en iOS ontwikkelaars) niet gebonden aan Chromium. Ik kan, op het moment van schrijven, gewoon Firefox voor Android gebruiken, of zelfs mijn eigen fork compileren via F-Droid of source. Chromium hoeft dus helemaal niet te weten wat ik doe. Die keuze ligt (voorlopig) bij mij, zolang die keuze me niet wordt afgenomen.

En dat is de kern van de discussie: keuzevrijheid, niet dogma. Immers, keuzevrijheid is per definitie geen misbruik van wetgeving, maar monopolie wél.

[Pyronick]

Dat geldt niet voor progressieve web apps want die draaien in de security context van de browser.

Je raakt een valide punt aan en legt gelijk de vinger op de zere plek: de security context van PWA’s is inderdaad cruciaal. Maar dat is nu juist waar ik in mijn eerste comment op doelde met “by design”.

Het punt is dat Apple en Google (of eigenlijk gewoon " Big Tech"), via hun dominante positie binnen de W3C, WHATWG en andere normerende fora, interest groups, gremia, etc, de ontwikkeling van sandboxing- en API-architecturen voor webapps bewust vertragen of blokkeren, vaak met halfslachtige of niet-onderbouwde argumenten (goed geleerd van Microsoft in het verleden).
Ze kunnen die standaardiseren, zoals ze dat ook doen bij native apps, maar doen het niet, omdat het hun distributiemonopolie ondermijnt.

Zolang de duopolie de standaardisatieprocessen domineert, blijft de browser afhankelijk van hun willekeur. Dáár hoort antimonopoliewetgeving in te grijpen: bij de normstellers, niet pas achteraf bij de appstores.
Wat de gevolgen zijn van dat soort scheefgroei zagen we eerder bij het OOXML-schandaal van Microsoft.

En over die “keuzevrijheid”: dat is een semantische schijnvertoning.
“Je kunt het product toch niet kopen?” is geen keuze als er geen gelijkwaardig alternatief bestaat.
Dat heet geen marktwerking, dat heet marktfalen.

Overigens ook een eervolle vermelding voor partijen die wél lef tonen, zoals Mozilla (soms ook een beetje te veel lef), dat ondanks beperkte middelen de vrije webstandaard blijft verdedigen, en zelfs grootbanken (wat we ook van ze mogen vinden) als ING en Rabobank, die inmiddels beseffen dat hun afhankelijkheid van Google Pay, Apple Pay maar ook PayPal, Visa en Mastercard een keurslijf is.

Pas nu de EU via de Digital Markets Act NFC-toegang weer verplicht openstelt, kunnen initiatieven als Wero überhaupt ontstaan.

Dáár zie je dus het verschil tussen een markt die wordt beschermd tégen macht, en een markt die macht beschermt tégen concurrentie.

[daanb14]

Overigens ook een eervolle vermelding voor partijen die wél lef tonen, zoals Mozilla (soms ook een beetje te veel lef), dat ondanks beperkte middelen de vrije webstandaard blijft verdedigen, en zelfs grootbanken (wat we ook van ze mogen vinden) als ING en Rabobank, die inmiddels beseffen dat hun afhankelijkheid van Google Pay, Apple Pay maar ook PayPal, Visa en Mastercard een keurslijf is.

Nou moet ik hier helaas bij de Rabobank wel een kanttekening bij plaatsen. De Rabobank heeft recent besloten de Play Integrity API in Strong Integrity mode te gebruiken om te bepalen of je de app mag installeren. Hiermee maakt de Rabobank het je (tenzij je de omweg met Aurora Store weet) onmogelijk om hun app te installeren op een Android telefoon die een op AOSP gebaseerde Android draait. Dat terwijl er een open hardware attestation API in AOSP zit waar de ROM distributeur zijn keys voor kan publiceren. De Rabobank zorgt er hiermee voor dat je niet om Google heen kunt als je geen iOS gebruikt en dat vind ik zeer kwalijk.

[wiseger]

Een OS bouwer maakt een OS en levert daarbij API's zodat ontwikkelaars eenvoudig applicaties voor dat OS kunnen ontwikkelen die gebruik maken de specifieke mogelijkheden die het OS te bieden heeft.

Zo werkt het met een computer OS zoals Windows met de Win API, zo werkt het met mobiele OS-en zoals iOS en Google Android.

Die API's hebben echter ook het effect dat een applicatie alleen werkt voor het OS waarvoor die applicatie ontworpen is. Dat noem jij monopolie misbruik.

Daarom vind jij dat een browser volledig toegang moet hebben tot alle API's van het onderliggende OS zodat ontwikkelaars alleen nog maar voor een browser hoeven te ontwikkelen en daarmee hun applicaties overal zouden draaien.

De browser wordt dan een universele schil om alle OS-en heen. En de applicatie ontwikkelaar wil je dan verplichten om altijd een browser applicatie te ontwikkelen in het kader van anti-monopoly wetgeving.

[Pyronick]

Een OS bouwer maakt een OS en levert daarbij API's zodat ontwikkelaars eenvoudig applicaties voor dat OS kunnen ontwikkelen die gebruik maken van de specifieke mogelijkheden die het OS te bieden heeft.
Zo werkt het met een computer OS zoals Windows met de Win API, zo werkt het met mobiele OS-en zoals iOS en Google Android.
Die API's hebben echter ook het effect dat een applicatie alleen werkt voor het OS waarvoor die applicatie ontworpen is.

Klopt.

Dat noem jij monopolie misbruik.

Dat volgt niet logisch uit het voorgaande, een non-sequitur. Niemand stelt dat het bestaan van API’s op zichzelf monopolistisch is.

Daarom vind jij dat een browser volledig toegang moet hebben tot alle API's van het onderliggende OS zodat ontwikkelaars alleen nog maar voor een browser hoeven te ontwikkelen en daarmee hub-applicaties overal zouden draaien.

Nee, dat is precies wat ik niet wil. Ik wil dat de browser en het OS respecteren wat de gebruiker vraagt en wat de context vereist, maar wel op een eerlijke manier die ook echte, dus geen valse, keuzevrijheid biedt voor zowel (eind)gebruiker als ontwikkelaar.

Als ik in de webapp van Google Foto’s een afbeelding upload, wil ik dat de browser en het OS samenwerken om alleen afbeeldingsbestanden (bijvoorbeeld via MIME-type of photo-picker) toe te staan. Niet dat de browser willekeurige toegang krijgt tot mijn hele bestandssysteem of hardware.

De browser wordt dan een universele schil om alle OS-en heen. En de applicatie-ontwikkelaar wil je dan verplichten om altijd een browserapplicatie te ontwikkelen in het kader van anti-monopoly-wetgeving.

Ook niet waar. Ik pleit juist voor keuzevrijheid: dat ontwikkelaars en gebruikers zelf kunnen bepalen of iets een native app of webapp wordt.

Bovendien, in zekere zin doen Apple (via WebKit) en Google (via Android WebView) dat al.

Wat nu misgaat, is dat grote OS-bouwers bewust bepaalde web-API’s blokkeren (zoals WebUSB, WebHID en WebNFC) maar in andere gevallen selectief toestaan. Daardoor worden onafhankelijke ontwikkelaars kunstmatig beperkt en ontstaat een dubbele standaard: sommige ontwikkelaars zijn meer gelijk dan andere.

Dát is pas marktverstoring, niet het bestaan van API’s zelf.

[wiseger]

Ik pleit juist voor keuzevrijheid: dat ontwikkelaars en gebruikers zelf kunnen bepalen of iets een native app of webapp wordt.

Dat is niet waar. Als een OS bouwer bepaalde API's om veiligheidsredenen niet vrij wil geven voor gebruik door een browser, dan noem jij dat een bewuste beperking.

Als elke app ook als progressieve web app moet kunnen werken, dan is de facto de situatie dat de browser volledig toegang moet hebben tot alle API's. Het OS moet dan volledig open zijn voor de browser.

Het OS is dan niet langer verantwoordelijk voor de veiligheid van de telefoon, het is de browser die dan die taak overneemt. En als Mozilla met FireFox dan de mist in gaat, en enorm lek introduceert waardoor alle iPhones ineens open staan, er op grote schaal misbruik van iPhones wordt gemaakt, wie is er dan verantwoordelijk voor de schade?

[Pyronick]

Dat is niet waar. Als een OS bouwer bepaalde API's om veiligheidsredenen niet vrij wil geven voor gebruik door een browser, dan noem jij dat een bewuste beperking.

Als die veiligheidsredenen goed gemotiveerd kunnen worden, prima.

De keuzevrijheid van de eindgebruiker en ontwikkelaar kan soms een beperking vormen voor de OS-bouwer. In een gezonde markt met meerdere serieuze concurrenten kunnen gebruikers of ontwikkelaars altijd uitwijken. In de praktijk is dat nauwelijks mogelijk: feitelijk zijn er alleen Apple en Google, tenzij je als tweaker of hacker buiten de lijntjes kleurt.

Als elke app ook als progressieve web app moet kunnen werken, dan is de facto de situatie dat de browser volledig toegang moet hebben tot alle API's. Het OS moet dan volledig open zijn voor de browser.

Niet elke app hoeft als progressieve web app te werken. De mogelijkheid om een PWA te draaien moet er wél zijn. Als een OS-bouwer dat om veiligheidstechnische redenen beperkt, moet die beperking eerlijk, transparant en controleerbaar onderbouwd worden. Veiligheid mag nooit een voorwendsel zijn om concurrentie of keuzevrijheid te beperken.

Grappig genoeg zijn veel zogenaamd (de meeste?) “native” apps in werkelijkheid gewoon webapps in een jasje, draaiend via frameworks als Flutter of Electron. Het onderscheid tussen “native” en “web” is dus vaak puur cosmetisch, en dat onderstreept mijn punt alleen maar, of beter nog: het legt de hypocrisie van Big Tech pijnlijk bloot.

[wiseger]

Je mist het punt.

Als elke app ook als progressieve web app moet kunnen werken, dan is de facto de situatie dat de browser volledig toegang moet hebben tot alle API's. Het OS moet dan volledig open zijn voor de browser.

Er zijn dan praktisch geen beperkingen meer wat de browser mag. Het is dan aan de browser om te voorkomen dat een malafide progressieve web app misbruik maakt van het gebrek aan beperkingen op OS niveau.

Het OS is dan niet langer verantwoordelijk voor de veiligheid van de telefoon, het is de browser die dan die taak overneemt. En als Mozilla met FireFox dan de mist in gaat, en enorm lek introduceert waardoor alle iPhones ineens open staan, er op grote schaal misbruik van iPhones wordt gemaakt, wie is er dan verantwoordelijk voor de schade?

Hoe gaan we daar dan mee om?

[Pyronick]

Als elke app ook als progressieve web app moet kunnen werken, dan is de facto de situatie dat de browser volledig toegang moet hebben tot alle API's. Het OS moet dan volledig open zijn voor de browser.

Maar dat is in feite al zo. De meeste moderne apps gebruiken onderhuids al WebKit (iOS) of Chromium WebView (Android). Instagram, Twitter, Discord, zelfs veel bankapps draaien grotendeels op webtechnologie binnen een sandbox. Electron-apps (VSCode, Slack, Spotify, etc.) zijn letterlijk browsers met OS-hooks. De grens tussen “native” en “browser” is dus allang kunstmatig, een kwestie van macht, niet van techniek.

Het OS is dan niet langer verantwoordelijk voor de veiligheid van de telefoon, het is de browser die dan die taak overneemt. En als Mozilla met FireFox dan de mist in gaat, en enorm lek introduceert waardoor alle iPhones ineens open staan, er op grote schaal misbruik van iPhones wordt gemaakt, wie is er dan verantwoordelijk voor de schade?

De wet is daar vrij helder over. Onder de Europese productaansprakelijkheidsrichtlijn (85/374/EEG), de Digital Services Act en de komende AI Liability Directive ligt de verantwoordelijkheid bij de softwareleverancier of platformbeheerder. Bovendien is er al 40 jaar aan jurisprudentie voor reguliere werkstations, desktops, etc.

Kortom:
• Als Mozilla een ernstig lek veroorzaakt, zijn zij aansprakelijk.
• Als Apple’s Safari of iOS een gat laat vallen, dan is Apple aansprakelijk, zij beheren immers het platform en dragen zorgplichten onder de Digital Markets Act.

Het risico dat jij schetst is dus niets nieuws; het geldt nu ook al voor Safari, WebKit en Android WebView.

Bovendien is dit hele model (“browser als app, maar eigenlijk ook mini-OS”) juist ontstaan door Google (Google Gears) en Apple zelf (vooral op smartphones sinds iOS 8 en Android 5.0). Zij hebben de browser omgevormd tot een gecontroleerde runtime, zodat PWA’s en webapps niet te veel konden, uit concurrentie-overwegingen, niet uit veiligheidszorgen.

[PureTryOut]

Electron prima, maar Flutter apps zijn echt geen web apps hoor. Ja het kan compileren naar JavaScript en dan dus als web app draaien, maar op desktops en mobiele platformen komt geen web code bij kijken.

[Houtenklaas]

Opgesloten zitten in een bepaald eco-systeem waar de fabrikant ook alle mogelijke moeite doet om randen van de wet op te zoeken en zelf gebruikers tegen wetgevers opzet - en de koper werkelijk ziende blind blijkt - is voor niemand goed.

[voorstad]

Ja


(Het staat de fabrikanten w.m.b. vrij om ook apps aan te bieden. Het gaat erom dat er altijd een web alternatief is. Voorkom #appdwang.)

[Houtenklaas]

Anti monopolie wetgeving is er zeker niet om App stores tegen te gaan, of technologieën te verbieden, dat weet je best. Het gaat erom dat anderen deze technologie ook kunnen gebruiken door API's te documenteren zodat je niet opgesloten zit in een ecosysteem van een muurtjesbouwer. Jij mag altijd gebruiken wat je altijd al deed, daar voel je verder niks van en daar ervaar je werkelijk geen enkel nadeel van. En nee, het argument dat in de toekomst wellicht xyz niet meer bruikbaar is op jouw favoriete merk telefoon geldt niet. Laat het eerst maar eens gebeuren.

[wiseger]

Ik heraal het nog maar eens keer.

Een OS bouwer maakt een OS en levert daarbij API's zodat ontwikkelaars eenvoudig applicaties voor dat OS kunnen ontwikkelen die gebruik maken de specifieke mogelijkheden die het OS te bieden heeft.

Zo werkt het met een computer OS zoals Windows met de Win API, zo werkt het met mobiele OS-en zoals iOS en Google Android.

Die API's hebben echter ook het effect dat een applicatie alleen werkt voor het OS waarvoor die applicatie ontworpen is. Dat wordt nu ineens monopolie misbruik genoemd.

Daarom vind Pyronick dat een browser volledig toegang moet hebben tot alle API's van het onderliggende OS zodat ontwikkelaars alleen nog maar voor een browser hoeven te ontwikkelen en daarmee hun applicaties overal zouden kunnen draaien.

De browser wordt dan een universele schil om alle OS-en heen. En de applicatie ontwikkelaar wil Pyronick dan verplichten om altijd een browser applicatie te ontwikkelen in het kader van anti-monopoly wetgeving.

[KoffieAnanas]

Huh, wat???

Zal ik hier serieus op reageren, of plaats je expres een flamebit?

Ik was eigenlijk al gestopt na je intro, en helemaal na punt 1. Je opmerking slaat kant nog wal.

Maar ik doe een poging. Kun je punt 1 toelichten? Google en Apple staan nu al alternatieve app stores toe, al dan niet daartoe gedwongen. Dit gaat prima samen met hun eigen app stores. Op Android zijn er zowel App stores van fabrikanten, zoals Samsung, als ook betrouwbare open source app stores.

[MN-Power]

Verplichten dat je een progressive web-app beschikbaar stelt in bepaalde gevallen(bijvoorbeeld banking apps) is toch geen verbod om óók een native app te maken?

[Houtenklaas]

Doel-redeneren heet zoiets. Bankieren op de laptop in een willekeurige browser werkt prima, waarom zou dat op een telefoon anders zijn?

[wiseger]

Bankieren op je laptop vereist een token generator. Op je telefoon in je banken app is dat niet zo.

Niemand wil internet bankieren in de browser met slechts een PIN code beveiliging.

[Houtenklaas]

Klopt, maar daar zijn dan ook weer deftige oplossingen voor. Het ging erom dat bankieren in een browser meer dan uitstekend werkt, dat is absoluut niet voorbehouden aan een native app.

[wiseger]

Maar de banken hebben juist net gekozen voor native apps omdat die erg veilig zijn. Met iOS en Android kan je veilig bankieren met slechts gebruik maken van een enkele PIN code.

De dure hard tokens worden notabene net uitgefaseerd. En dan moeten ze ineens verplicht worden?

Banken zitten ook helemaal niet op te wachten om al die ellende met spoofing en phishing terug te krijgen , alleen maar omdat de overheid ze zou moeten verplichten progressieve web apps te bouwen? En als dat van de overheid moet, zijn banken dan ook weer verplicht al die mensen die erin trappen wederom schadeloos te stellen, zoals tien jaar geleden gebeurde? Heeft de banken tientallen miljoenen euro;'s gekost.

Het is allemaal nergens voor nodig. Een OS heeft eigen, unieke features die ontwikkelaars graag gebruiken. En daarvoor maken ontwikkelaars gebruik van API's. Die zijn uniek omdat OS bouwers graag een uniek systeem bouwen dat mensen graag gebruiken. Daarom hebben we gelukkig vele smaken OS-en met ieder zijn voors- en tegens. In plaats van één browser to rule them all.

[Houtenklaas]

De initiële vraag was of je een bankwebsite met een browser kan benaderen en dat antwoord is simpelweg "ja", alleen al omdat het zeer eenvoudig aan te tonen is dat dat kan. Alles wat je er verder bijhaalt is irrelevant, ruis en leidt af van de hoofdvraag. Enige focus op die hoofdvraag wordt op prijs gesteld.

[wiseger]

Nee dat was niet de vraag, de vraag was of dat kon zonder van alles te veranderen.

Met een native banken app kun je onderweg in de trein naar je werk heel eenvoudig betalingen doen. Met een progressieve web banken app kan dat niet, dan heeft u ineens een pasje een een hard token zoals de Rabo Random reader of ABNAMRO e.dentifier nodig. Heel gedoe in de trein.

Hetzelfde speelt op vakanties in het buitenland. Nu kan een ieder eventjes inloggen met de native banken app en het saldo checken, zo hou je grip op je vakantie uitgaven en merk je problemen vroegtijdig op. Maar met een progressieve web app heeft u ineens de Random reader of e.dentifier nodig. Oops vergeten mee te nemen. Geen banken app tijdens de vakantie.

Het is gewoon appels met peren vergelijken.

[Houtenklaas]

Grappig he, het artikel gaat over een alternatief OS, we hebben het over webapps en ineens haal je trein en vakantie erbij. Is het nu zo lastig om je tot de hoofdzaak te beperken? Waarom al die zijpaadjes die nergens heen gaan?

Webapps zijn simpelweg een uistekend alternatief. Is het 1:1 vervanger voor een native app? Nee, er zal echt wat moeite in gestoken moeten worden. Met de insteek "hou het maar zo" hadden we nu nog met stoommachines gezeten. De wereld gaat vooruit, software lijkt richting (streaming) web applicaties te verschuiven en daarmee is er behoefte aan andere oplossingen die er overigens nu al zijn. Denken in beperkingen heeft de mensheid nooit vooruit geholpen.

Daarnaast kan een bank mij nooit verplichten om uit twee OS'en te kiezen van datagraaiers, die keuze maak ik en niemand anders.

[wiseger]

De door mij aangehaalde voorbeelden laten goed zien hoeveel gemak de native app versie iemand biedt t.o.v. een progressieve web app. Het is gewoon niet hetzelfde.

Of de bank je kan dwingen te kiezen tussen twee smartphone OS-en? Die kans is vrij groot nu de meeste banken stoppen met de hard tokens. Maar wie weet is er wel een bank die een hard token in leven laat of kan je via de post je overschrijvingskaarten insturen. Alleen zullen ze daar wel kosten voor rekenen.

[Finraziel]

Nou zit ik er helemaal niet in dus misschien zie ik iets compleet over het hoofd... Maar banken werken ook gewoon in websites. Hoe is zo'n app anders? Ja voor sommige functionaliteit zal er wat extra toegang tot de telefoon moeten zijn (scannen van codes, betalen met je telefoon) maar de basis functionaliteit van een bank app kan prima zonder enige verdere toegang tot je systeem toch...

[wiseger]

Op websites hadden we al het grote probleem van phising websites. Mensen die naar een website geleid werden die eruit zag als hun bank. De banken app heeft dit probleem opgelost. Met progressieve web apps creëer je exact dit probleem weer.

Een banken website maakt gebruik van een externe token generatie. Op je telefoon staat een beschermde, veilige app waarmee je de QR code scant en dan wordt er een OTP gegenereerd. Die app start alleen na een authentificatie van de gebruiker. Dat heb je alleen niet meer als het een progressieve web app is.

Verder draait een progressieve web app in de security context van je browser. Dus alle rechten die de app nodig heeft, zoals camera toegang, ken je toe aan je browser. Waarna alle progressieve web apps dat recht toegewezen krijgen. dus ook wanneer je per ongeluk een malafide progressieve web app in je browser laad.

De basisfunctionaliteit van je banken app gebruikt geheime informatie op je telefoon die je niet open wil hebben staan voor alle progressieve web apps. Want dan is er weinig geheims meer aan.

[readefries]

Dat geldt trouwens óók voor GPL-licenties, die al jaren massaal worden geschonden (m.b.t. misbruik van Linux).

Hoe bedoel je dit? Bedoel je dat het niet delen van aanpassingen, of het niet tonen van gebruik?

[Pyronick]

Hoe bedoel je dit? Bedoel je dat het niet delen van aanpassingen, of het niet tonen van gebruik?

Beide, in de breedste zin.

Je komt af en toe consumentenelektronica tegen die bewust probeert te verbergen dat er Linux onder de motorkap draait, bijvoorbeeld door user agents of systeem­identifiers aan te passen zodat het lijkt alsof het *BSD is, vanwege de vrijere BSD-licentie.

Hetzelfde zie je bij libraries of middleware die onder de GPL-licentie vallen, maar worden “vermomd” als MIT-varianten. Alleen verraadt soms de stderr of een onverwachte output dat het in werkelijkheid om een GPL-gelicentieerde component gaat. In de praktijk zie je het vooral bij ffmpeg en GStreamer, maar BusyBox en glibc voeren de hitlijst van GPL-schenders aan, legio voorbeelden, en geen enkel excuus.

[Reactie gewijzigd door Pyronick op 10 oktober 2025 17:09]

[readefries]

Ah zo, bedankt voor de verduidelijking.

Helemaal met je eens dat die kwalijk is, wees dan eerlijk dat je gebruik van (F)OSS maakt. En het liefst ook nog eraan bijdraagt natuurljk :)

[Qwerty-273]

Het probleem is dan ook dat de meeste ontwikkelaars bij commerciele bedrijven geen tijd/resources/geld/zin hebben om alles zelf te ontwikkelen. Dan is het leunen op heel veel "standaard aanwezige" Google API's een stuk makkelijker. En ja dan zit je vast aan Android en ja aan Google. Hoe ga je anders verifiëren dat je app niet in een virtuele container draait, of dat er een overlay over je app valt die alle input en output verzameld.

Het grootste struikelblok zit bij de omarming van bedrijven die apps maken. Dat zag je ook ten tijde van Windows Phone (wie kent dat nog?) en tal van andere mobiele besturingssystemen die wel van de grondkomen maar blijven steken op appjes ontwikkeld door de fans en de bedrijven die daar geen tijd in steken en je dus een groot deel van je commerciële apps (en dat is ook een bank app of een kaart/navigeer app) zal missen.

Een opensource telefoon kan je ook bijvoorbeeld in de Precursor vinden.

[readefries]

Dan is het leunen op heel veel "standaard aanwezige" Google API's een stuk makkelijker. En ja dan zit je vast aan Android en ja aan Google.

Wat betreft Android heb je daar ook meer dan genoeg mogelijkheden om het vrij te houden. Kijk b.v. naar local notifications, je hebt helemaal geen Google infra nodig om berichten te sturen en ontvangen op Android. Het is in veel situaties ook nog eens helemaal niet wenselijk dat ze langs Google gaan, en er is out-of-the-box gewoon support voor. Gelukkig zijn er messaging apps die dit begrijpen en ook mail clients.

Hoe ga je anders verifiëren dat je app niet in een virtuele container draait, of dat er een overlay over je app valt die alle input en output verzameld.

Hier is ook wel wat meer context nodig, want we hebben bij bank apps al gezien dat Google je niet kan blindstaren op wat Google vertelt, doordat ze ook beter beveiligde Android smaakjes (zoals GrapheneOS) als onveilg afschilderen.

[The Zep Man]

Wat betreft Android heb je daar ook meer dan genoeg mogelijkheden om het vrij te houden. Kijk b.v. naar local notifications, je hebt helemaal geen Google infra nodig om berichten te sturen en ontvangen op Android.

Dat ligt eraan welke smartphone je hebt. Als een applicatie op de achtergrond de nek wordt omgedraaid dan zal die zelf geen notificaties meer ontvangen.

[readefries]

pff, klopt helemaal. Sommige fabrikanten zorgen voor veel issues als je apps ontwikkeld.

[Sandor_Clegane]

Als ze whatsapp en signal ondersteunen, wil ik hem wel hebben.

Ik maak tegenwoordig expres minder gebruik van mijn telefoon.

[The Zep Man]

En juist daar zit normaal het probleem en waarom ik geen toekomst zie in dit soort projecten. De teletoon maken is een ding en daar zijn al diverse open source projecten voor aanwezig. Maar vervolgens heb je geen apps en wil niemand het gebruiken.

Daar kan Waydroid bijspringen. Gecombineerd met microG en verdere verfijning lijkt mij dat compatibiliteit prima kan zijn. Vergelijk het met Valve die Proton ontwikkelt.

Het grootste probleem is niet de software, maar hardware. Huidige smartphones gebruiken binaire blobs die gekoppeld zijn aan bepaalde Linux kernelversies. Er zijn een paar smartphones uitgekomen die dit omzeilden door enkel opensource drivers te gebruiken, maar het probleem is dat de hardware sterk verouderd is voordat het uitkomt en dat de prijs te hoog is voor wat je krijgt.

[Reactie gewijzigd door The Zep Man op 10 oktober 2025 16:40]

[PMvE]

worden apps niet steeds vaker in een browser gedraaid waarmee porten erg makkelijk is?

[m-a-r-t-1]

Inderdaad, ik heb een aantal jaar een Sailfish telefoon gehad. Via Android emulatie was een hoop werkend te krijgen. Net als met LineageOS, werkt perfect. Maar het werd een steeds grotere dagelijkse struggle om alles werkend te houden. En dat had ik op een gegeven moment echt geen zin meer in. Dus toch maar weer een 'normale' android telefoon zodat zaken als bank apps gewoon blijven werken zonder weer van alles aan de hand moeten halen iedere keer.

[BadRespawn]

Android laat een gat in de markt vallen voor een echt open teletoon.... Met alle apps die je normaal kan draaien, app van de bank, etc.

Ik denk dat verreweg de meeste consumenten ruimschoots tevreden zijn met Android of iOS en de apps die daarop draaien. Dus zo groot is dat gat niet, het is eerder een niche.

[Knallmeister]

Zouden bank-apps DigiD en meer van dergelijk soort apps ook voor dat opensourcebesturingssysteem voor telefoons ontwikkeld en ondersteund gaan worden? Als dat niet het geval is, dan zal er geen grote groep mensen zijn die zo'n opensource besturingssysteem op hun telefoon willen installeren, of er een extra telefoon voor willen aanschaffen.

Zelf zou ik er geen groot probleem mee hebben om een extra telefoon voor aan te schaffen om mee te doen met dit experiment (waarvan ik hoop dat het een succes wordt), al was het alleen maar om daarmee de afhankelijkheid van de play-store te verkleinen. (Als dat mogelijk is). En van de grillen van de telefoon-fabrikant die z'n eigen apps pusht (waar ik ook niet echt dol op ben).

[Reactie gewijzigd door Knallmeister op 10 oktober 2025 17:12]

[dmantione]

Nou ja, het mantra van de FSF is altijd geweest dat er nul komma nul compromissen gesloten worden. Men zal dan ook geen haar toegeven om bankapps te kunnen draaien. En in grote lijnen heeft die aanpak gewerkt: Iedereen wil Linux gebruiken omdat je héél veel voor niets krijgt. Zelfs Google doet het met Android.

Tegelijkertijd is de FSF soms te gesloten geweest voor de praktijk: Eén van de redenen waarom GNU/Hurd niets werd is dat het te standvastig vasthield aan het toestaan van zaken als binaire drivers of binaire firmware meeleveren voor hardware. Linux was technisch beter dan Hurd, maar de pragmatische aanpak van Linus Torvalds was ook nodig.

Een mogelijke toekomst is dat de FSF wederom de basis van een besturingssyteem neerlegt en anderen pragmatische aanpassingen gaan maken zodat je bijvoorbeeld kan bankieren.

[TrekVogel]

Je slaat de spijker op zijn kop. Ja, ik vind open en vrij mooi en belangrijk maar het moet ook praktisch zijn. Dingen moeten het ook gewoon doen. Ik gebruik Linux Mint als mijn standaard OS en dat is een mooie balans. Ik juich een open telefoon OS toe maar het moet wel enigszins praktisch zijn. Ik ben niet heel veeleisend qua apps maar WhatsApp bijvoorbeeld is helaas wel nodig.

En wie zou de hardware willen maken? Samsung heeft al heel wat pogingen gewaagd maar heeft uiteindelijk toch alles op Android gegooid.

[Some12]

“App gap”, whatever… Het is gewoon maatschappelijke onwil om een open samenleving te hebben, waar je als individu gewoon niet gegunt wordt om digitale vrijheid te hebben: een enkele wet die verplicht alles webapp toegakelijk te hebben en anders de markt uit… waar is dat? Precies: de politiek geeft er niks om.

[wiseger]

Die wet zal er niet komen omdat juist de native apps veel problemen met bijvoorbeeld phising websites hebben opgelost. De overheid heeft niet voor niets Digid als native app ontwikkeld, juist omdat het zo veilig is.

Apple en Google hebben hun mobiele OS-en zodanig veilig gemaakt, dat mensen die vertrouwen. Waardoor je dus rustig je bankzaken doet met slechts een enkele PIN code als invoer.

Met een progressieve webapp ga je terug in de tijd, toen we nog alles op de computer in een browser deden. Met ook een herintroductie van alle problemen die we toen hadden.

[Houtenklaas]

Die wet zal er niet komen omdat juist de native apps veel problemen met bijvoorbeeld phising websites hebben opgelost. De overheid heeft niet voor niets Digid als native app ontwikkeld, juist omdat het zo veilig is.

Exact het verkeerde voorbeeld. Digid kan je gewoon op inloggen zonder telefoon, zonder welke app dan ook. Die hebben uitstekend door dat je geen native apps kunt verplichten. En dat hoeft ook niet, er zijn genoeg opties om veiligheid te garanderen buiten je telefoon om. Misschien iets meer moeite ja, maar dat heb ik er graag voor over om niet in een digitaal spinneweb te zitten.

O ja, ls je een link hebt die aantoont dat phishing is opgelost door het gebruik van Android/Apple laat ik me graag verrassen, ik zie alleen maar berichten dat fraude met phishing enorm toegenomen is, niet alleen bij banken, maar over de hele linie.

[Reactie gewijzigd door Houtenklaas op 11 oktober 2025 18:47]

[wiseger]

DigiD is juist een heel goed voorbeeld. Doordat de smartphone zo veilig is, kan je daar je DigiD activeren door de chip van je ID uit te laten lezen. Zo krijg je een zeer veilige koppeling.

Vergelijk dat eens met de web versie van DigiD. Dan moet je een brief aanvragen. Wordt je op basis van de basisregistratie personen toegestuurd. Met die code met je je DigiD activeren en als je geen gebruik maakt van SMS dan krijg je een gebruikersnaam / wachtwoord combinatie. Geen 2FA dus.

DigiD op de smartphone is gewoon veel veiliger dan via het web.

[Niema]

In de meeste situaties is de DigiD app niet nodig en is de code ook te ontvangen via sms. Mocht specifieke functionaliteit van de DigiD app nodig zijn dan kun je het ook gebruiken binnenin een Android waydroid container. Voor mn belastingaangifte heb ik iig de app niet nodig.

[Triblade_8472]

Heel simpel, dat hangt van 't marktaandeel af.

Zijn er 10 mensen in Nederland gaan ze dit nooit vrijgeven.

Draait 30% van Nederland dit OS, hebben ze gewoonweg geen keus meer en moeten ze wel.

[Finraziel]

En dat is het probleem, zonder die apps zal het al lastig worden 1% te halen, laat staan 30.

[teek2]

Ik zie het heel graag gebeuren, maar ik hoop dat ze leren van GrapheneOS en Ubuntu Mobile, en Phosh/Purism, postmarktetOS, dat FireFox OS wat er ooit was...

Het is denk ik heel erg moeilijk om geld te verdienen met de ongetwijfeld niet-flagship waardige hardware die ze zelf moeten gaan maken ergens. Het is een enorme Niche.

Tegelijkertijd lijkt het steeds makkelijker om in China iets van goede kwaliteit in elkaar te laten zetten (zie de Pebble reboot).

Laat ze aub gaan samenwerken met FairPhone, en goede afspraken maken over het hardware platform. Er is te veel variatie in hardware om het generiek te maken denk ik anders.

[Reactie gewijzigd door teek2 op 10 oktober 2025 16:40]

[rustycrab]

GrapheneOS is in die zin (voor nu) ideaal. AOSP gebasseerd dus veel compatibiliteit qua apps en (heel) veel privacy en veiligheids features.

En Pixel smartphones zijn prima toestellen.

[Reactie gewijzigd door rustycrab op 10 oktober 2025 16:46]

[teek2]

Maar dus niet lange termijn houdbaar omdat ze zo afhankelijk zijn van Google en Pixels. Ze krijgen nu geen device drivers meer mee met AOSP en staan direct buiten spel.

[rustycrab]

Precies. Dat is de langzame afgang van het vrije Android. Dacht wel dat GrapheneOS de pixel 10 nog kan ondersteunen.

Bron: https://x.com/GrapheneOS/status/1960792610114511190

[teek2]

Het kan allemaal misschien nog lang goed gaan, maar de situatie laat wel goed zien waarom je wel een volledig open OS wilt, en dus ook het liefst een hardware manufacturer die je op zijn aller minst niet tegenwerkt + een soort belangen alignment die garandeert dat ze dat ook niet gaan doen.

[Reactie gewijzigd door teek2 op 10 oktober 2025 22:07]

[L0g0ff]

Ja eens. Ik draai ook AOSP/GrapheneOS op een pixel 7a

Dit werkt totdat je toch tegen geslotenheid aan botst. Een gesloten modem driver bijvoorbeeld die vanwege Samsung/Google beleid geen updates krigt en je zit met een battery drain op je mobile data 4g/5g. Dan snak je naar een full blown opensource telefoon. Inclusief open firmware en exclusief gesloten driver blobs.

[rustycrab]

Ja je gaat altijd op een gegeven moment tegen afhankelijkheden aanlopen inderdaad. Nu is het inderdaad voor de 7a wel snel moet ik zeggen (3,5 jaar)

[L0g0ff]

Ja de pixel 6 en 8 hebben er ook last van. Vanaf 9 gaat het iets beter. Maar een opensource driver zou het oplossen omdat er altijd wel iemand is die kan helpen. Of het helpt met het blootleggen van de root cause waardoor je een workaround kan inbouwen.

[PureTryOut]

Ik hoop vooral dat ze niet zomaar hun eigen ding gaan doen en samenwerken met de bestaande projecten zoals postmarketOS. Ok wij (postmarketOS) streven niet naar 100% vrije software tot het niveau dat de FSF doet maar we kunnen hen prima vertellen waarom dat in feite helaas een onmogelijke taak is en ons best doen wel zo dichtbij mogelijk te komen.

[RogerWilco2]

Het zal vooral afhangen van welke apps ondersteund worden, en op welke hardware het draait. Zelfs Microsoft heeft het niet gered vanwege die redenen.

[Frankzzz]

Grote partijen gaan dit actief tegenwerken. Microsoft apps werken bewust niet in een mobiele browser, je moet de app gebruiken. Die gaan ze never nooit ontwikkelen voor dit project. Op dit soort manieren wordt het nooit meer dan een niche

[-Colossalman-]

Ik gebruik juiste alleen de web versie anders is het exit. Nog geen belemmeringen tegen gekomen

[Frankzzz]

Ms Teams, kan niet via mobiel web.

En nu is er een security regel ingetreden dat outlook alleen via edge kan, maar ook de intune app geïnstalleerd moet zijn.

Kan ik wel zeggen exit, maar toch niet handig om je werk agenda niet in te kunnen zien.

[PureTryOut]

Microsoft heeft het niet gered omdat hun voornaamste doel was om er geld aan te verdienen. Dat probleem hebben Linux distributies e.d. niet, en zeker de FSF ook niet. Dus het zal wel loslopen, zolang ze maar niet bestaande projecten negeren en compleet hun eigen ding gaan doen.

[Insomnia1988]

Hopelijk komt er een goed alternatief voor Android, ik gebruik nu Grephenos. Maar Windows Phone blijft toch nog altijd voor mij de topper wat werkte dat toch goed zeg ( Nokia 920 en Nokia 930 gehad ). Om de Bank app te kunnen gebruiken heb je bijvoorbeeld nog altijd de google play store nodig, ik durf de bank app gewoon weg niet te side loaden. en hopelijk maken developers dan ook App voor dit soort OSen ipv dat kinderachtig gedoe op Windows Phone.

[readefries]

Je kan toch gewoon Aurora Store gebruiken? Die gebruikt de infra van Google, maar dan vanuit verschillende locaties en zonder dat je hoeft in te loggen: Google hoeft helemaal niet te weten wat je allemaal gebruikt. Naast F-droid zijn dat de enige bronnen voor mij om apps op mij Graphenos telefoon te installeren :)

[Insomnia1988]

Heel erg bedankt!


@PureTryOut Yes ben ermee bezig ook heel erg bedankt voor deze informatie.

[readefries]

Graag gedaan!

Triodos werkt ook als mobiele website, en heeft ook geen afhankelijkheid van Google PlayServices.

Correctie, je hebt wel MicroG of GraphenOS middleware nodig

[Reactie gewijzigd door readefries op 10 oktober 2025 21:01]

[PureTryOut]

Ik weet niet welke bank je gebruikt maar er zijn banken zoals ASN waarbij 1. de app prima zonder Google diensten werkt als je het download via b.v. Aurora Store en 2. de app niet eens nodig is omdat de website ook mobiel-vriendelijk is en hetzelfde kan.

Wellicht is overstappen een idee om te overwegen? 😉

[vickypollard]

... maar geen daarvan heeft ooit echte populariteit weten te bereiken

En dat gaat ook voor dit project gelden. Zolang smartphones en bedrijven met apps werken is er geen ruimte voor kleine spelers.

[readefries]

Ah wie weet kan het dezelfde influx geven als GNU/Hurd ooit gegeven heeft. Ook heeft GNU/Hurd eigenlijk nooit het daglicht echt gezien, alles wat erom heen gemaakt heeft zien we nog terug in alle Linux distributies :)

[PureTryOut]

Wat mensen altijd weer noemen bij dit soort berichten, ik hoor dat bij ons bij postmarketOS maar ook hier in de reacties weer, is dat dit soort platformen geen kans maken op grote getalen gebruikers door het missen van <insert app here>. Vaak wordt ook de vergelijking met Windows Phone gemaakt, waar natuurlijk miljarden in gestopt is maar nu toch echt niet meer bestaat door "te weinig marktaandeel".

Wat deze mensen missen is dat het de mensen die aan dit soort platformen werken, zoals ik, niet te doen is om hoge marktaandeel en vele miljoenen gebruikers, en wij vinden onze platformen niet "mislukt" of iets dergelijks als we niet op gelijke voet komen met Android en iOS. We verdienen er toch geen geld aan, dus verlies kun je niet maken. In plaats daarvan werken we aan een platform die voor de gebruiker werkt met lange ondersteuning, niet ad-infested is en je privacy als nummer 1 doel heeft. Een platform waar wij op de eerste plaats zelf heel gelukkig van worden.

Natuurlijk vinden we het vervelend dat banken steeds meer apps vereisen die vervolgens niet op ons platform draaien, en dat zaken zoals DigiD niet beschikbaar zijn. Maar eerlijk zijn, die gebruik ik op Android ook al niet en ik overleef het toch echt prima dus die ga ik op Linux mobile ook niet missen. Intussen werken wij aan een stabiel OS die mij niet in de steek zal laten als gebruiker en zijn we blij met iedere gebruiker, of er dat nou 1 is of duizenden. En op den duur komt er dan ook Android-app compatibiliteit zodat ook de mensen die dat soort dingen wel gebruiken er ook overweg mee kunnen. Er zijn al projecten zoals WayDroid en Android Translation Layer die hier hard aan de weg timmeren, maar dat zijn projecten van de lange adem.

[Pyronick]

Dank voor je werk!

Ik gebruik postmarketOS op mijn oude Surface Pro, en de combinatie van Alpine Linux en systemd is echt goud waard! Helaas nog niet op mijn smartphone... Maar naarmate meer apps worden ge-refactored naar GTK4, Qt6 en andere portrait/landscape-touchscreen-GUI’s, begint het wel steeds meer te kriebelen.

Wat ik me afvraag: wordt er al gewerkt aan een open vervanging van Apple CarPlay en Android Auto? postmarketOS zou daar immers perfect voor kunnen zijn. De push zal vermoedelijk uit de Phosh-, GNOME- of KDE-community moeten komen (die ontwikkelen tenslotte de apps en omgeving), maar hardware-technisch gezien zou zoiets prima moeten kunnen draaien op bijvoorbeeld een Raspberry Pi Zero met Wi-Fi of via USB-OTG.

[PureTryOut]

Voor de server kant (de auto head unit zeg maar) bestaat al een open-source implementatie die op Raspberry Pi's e.d. draait. De client kant, wat je telefoon doet, is echter op dit moment niet open-source en zonder Google diensten op Android mogelijk. Er wordt wel wat gereverse engineered maar er gebeurt niet veel en gaat niet snel helaas.

[aaahaaap]

Waar werk je aan binnen postmarketOS? Ik ontvang als het goed is vandaag een tweedehands 6T, aangeschaft om te proberen wat bij te dragen aan de ports/functionaliteit van postmarketOS :)

[PureTryOut]

Ik beheer voornamelijk er de volledige KDE stack voor, en verder algemene package maintenance.

Mooi om te horen! De OnePlus 6T is een goede keuze, veel plezier er mee!

[aaahaaap]

Cool! Plasma Mobile ziet er van wat ik tot nu toe gezien heb wel uit als een van de betere GUI opties voor mobile. Vind de flow/UX van Phosh of GNOME niet heel logisch met de window switcher boven de app iconen. Dus denk dat ik begin met Plasma Mobile/jouw werk ;)

In ieder geval, bedankt voor je werk aan postmarketOS!

[RobVI]

De ontwikkelaars achter GrapheneOS zijn ook bezig met een telefoon voor hun besturingssysteem om hun afhankelijkheid van Pixel telefoons te verkleinen.

[readefries]

Ah, dat klinkt wel interessant. Waar heb je dat gelezen? Ik kan het op hun site zo niet vinden

[RobVI]

https://x.com/GrapheneOS/status/1968727862401290467

[rustycrab]

Ben zeer benieuwd. Heel mooi initiatief in ieder geval! Telefoons is gewoon wat complexer dan computers. Voornamelijk vanwege software beschikbaarheid (apps)