GrapheneOS omzeilt Googles maandenlange embargo op Android-beveiligingsupdates

GrapheneOS komt met aparte previewreleases om gebruikers toch snel beveiligingsupdates te geven. De op beveiliging gerichte Android-aftakking omzeilt hiermee het kwartaalritme waarin Google beveiligingsupdates voor Android uitbrengt en wat aanvallers kansen zou geven.

Het opensourceproject geeft gebruikers van ondersteunde Pixel-smartphones daarmee sneller updates voor deze aftakking van het mobiele besturingssysteem Android. Dit is in reactie op het besluit van Google om beveiligingsupdates voor Android voortaan op kwartaalbasis uit te brengen.

GrapheneOS heeft de nieuwe previewmogelijkheid begin deze maand aangekondigd. Een tweaker meldt nu dat de op beveiliging en privacy gerichte Android-rom de uitnodiging geeft om 'Security preview releases' aan te zetten. Om de geheimhoudingsverplichting niet te schenden, brengt GrapheneOS de beveiligingsupdates uit als binaire releases. Openbaar maken van de broncode mag pas zodra Google de Android-updates officieel uitbrengt voor het Android Open Source Project (AOSP).

Die vertraging door Google moet smartphonefabrikanten tijd geven om updates te testen en geschikt te maken voor hun toestellen. Een neveneffect kan echter zijn dat dit maandenlange uitstel aanvallers kansen geeft, waarschuwde GrapheneOS begin september. De Android-patches van Google worden namelijk breed verspreid onder hardwarefabrikanten en veel ontwikkelaars hebben er dan toegang toe. Google legt weliswaar geheimhoudingsverplichtingen op, maar toch kan gevoelige beveiligingsinformatie in handen komen van spyware- en malwaremakers.

Reacties (82)

[Soldaatje]

Als ik het goed begrijp geldt het nieuws over het vertragen van deze updates alleen voor Google's eigen Pixel telefoons op dit moment?

[RobertMe]

Nee, het geldt alleen voor Graphene, en eventuele andere open source ROMs. Een Samsung bv zal de patches wel onmiddellijk ontvangen en mag deze ook toepassen maar niet de code publiceren. Vervolgens kunnen ze dus ook elke maand of wat dan ook een update uitgeven waar deze security patches in zitten, zolang het maar puur de binairy release is (en niet de code).

Alleen staan OEMs nu niet echt bekend om het snel oplossen van security issues. Als in: zelfs als Google de patches aanlevert zijn ze niet erg fanatiek met het daadwerkelijk uitbrengen van updates. Daarom dat Google de cyclus waarin ze de patches openbaren verlengt (van elke maand naar elke 3 maanden).
Een vorm van securuty through obscurity dus. Doordat de patches die het lek dichten niet openbaar zijn is het ook niet mogelijk om deze informatie te gebruiken om te achterhalen wat het lek was.
Het enige (nogal grote) nadeel is dus dat alternatieve ROMs (zoals Graphene, Lineage, ...), die juist wel vaak elke maand updates uitgaven met de laatste security fixes, nu juist helemaal geen fixes meer kunnen uitgeven buiten die 3 maanden cyclus en daardoor juist vatbaar(der) worden.
Maar als je een officiële ROM (zoals door de fabrikant geleverd) gebruikt zou er effectief dus niks hoeven te veranderen. Aangezien zij wel nog steeds elke maand een security update mogen uitgeven met de patches die nog onder het embargo vallen. Maar..., ik zie het wel gebeuren dat de fabrikanten die het nu goed doen vervolgens niet meer de noodzaak inzien om het goed te blijven doen en bv ook minder vaak updates gaan uitgeven (en dat bv een week voordat het embargo vervalt doen, zodat ze wel "veilig" zitten als de patch (/het lek) wel openbaar wordt)

[Vaevictis_]

Toevallig dit gisteren aangezet, je krijgt dus meteen de binary patches maar pas later de uitleg over de kwetsbaarheid. Erg goed want dit was een van de redenen om over te stappen vanaf Samsung.

[timeraider]

Verduidelijking in de comment als reply.

###################### Orgineel
Nee, het vertragen van updates gaat voor alle Android apparaten gebeuren. Dit zal effect hebben op alle merkenen officiele Androidversies voor alles van Samsung tot de kleinere aftakkingen.
Ze zullen zich allemaal aan de NDA moeten houden n hun updates niet uitbrengen tot dit word toegestaan.

[Reactie gewijzigd door timeraider op 13 oktober 2025 15:41]

[RobertMe]

Het embargo heeft juist geen betrekking op "updates", maar alleen betrekking op de broncode. Fabrikanten mogen dus prima updates uitgeven waar deze security fixes (die Google ze dus onder NDA geleverd heeft) in verwerkt zitten. Zolang ze de broncode maar voor zichzelf houden. En dat is wat Graphene nu dan ook gaat doen. Closed source updates uitgeven, met elke 3 maanden dan het publiceren van de broncode (van deze security fixes).

Als je de officiële ROM van de fabrikant gebruikt veranderd er in principe dus niks. (Tenzij je onder de open source licentie de broncode zou opvragen, of de fabrikant hun update beleid/schema aanpast naar aanleiding hiervan).

[Otter10Gbe]

Hoe groter GrapheneOS wordt, hoe bezorgder ik denk dat Google iets stoms zal doen, zoals ze buitensluiten.

[Pendora]

nieuws: Rabobank-app werkt niet meer op alternatieve Android-roms vanwege Integrity-api

Ze zijn allang begonnen helaas

[rustycrab]

Merk dat ik steeds meer lak ga krijgen aan diensten niet kunnen gebruiken vanwege de regeltjes die Big tech jongens als Google opstellen. Dan doe ik het maar via de browser op mijn Linux machine.

Het is zorgwekkend dat we in een situatie terecht zijn gekomen waarin een commerciële partij als Google effectief kan bepalen op welke apparaten we toegang hebben tot essentiële diensten zoals onze bankzaken. Doordat banken afhankelijk zijn van Google's Play Integrity-mechanismen — die niet beschikbaar zijn op alternatieve besturingssystemen zoals GrapheneOS — worden gebruikers feitelijk uitgesloten, puur vanwege de dominante positie die partijen als Google en Apple gezamenlijk innemen op de smartphonemarkt.

[jmignolet]

Ben ik met je eens. Dan is de kans groot dat je beperkt zal worden tot je bankzaken enkel in een browser te doen en is in principe prima. Ik ben er zelf ook niet blij mee voor alle duidelijkheid.

Mijn bank wordt nog op GrapheneOS ondersteunt gezien je de Play store kan installeren + play services. Je bent alsnog exposed, maar weliswaar in een sandbox omgeving. Maar dat staat niet los van het feit dat je dus per se via die app store moet doorgaan. Je doet het eigenlijk gewoon op een andere manier.

[kozue]

Mijn bank wordt nog op GrapheneOS ondersteunt gezien je de Play store kan installeren + play services.

En zo wordt je door andere partijen zoals banken gewoon gedwongen om Google troep op je alternatieve OS te installeren. Dat zijn echt kwalijke zaken, waar best eens regelgeving voor mag komen om ons als consument te beschermen tegen big tech.

[Cafe Del Mar]

Als mijn bank me zoiets lapt, ben ik daar weg (behalve mijn hypotheek).
Er zijn genoeg andere banken die soortgelijke diensten of producten aanbieden, ik heb niets exotisch nodig. Dus als hun conclusie is dat ik van hen niet meer mag bankieren, dan ga ik wel ergens anders bankieren.

[RobertMe]

Beste kans natuurlijk dat alle banken dit gaan doen. Onder het mom van veiligheid en dat zij niet kunnen garanderen dat een alternatieve ROM veilig is. Anderzijds zijn juist de officiële ROMs uiteraard wel weer vaak onveilig, doordat fabrikanten of geen updates meer uitgeven voor een ouder toestel, of gewoon ronduit laat updaten (bv 1x per jaar een Android update en verder geen maandelijkse nu kwaartaal-lijkse security updates uitgeven). Terwijl juist in mijn ervaring die alternatieve ROMs wel netjes maandelijks de security updates uitgeven.

En waar Rabobank de app nu niet meer aanbied via de Play Store, waar schijnbaar omheen te werken is, is Revolut nog veel harder. App is van de ene op de andere dag onbruikbaar omdat toestel niet aan Play Integrity voldoet.

[WernerL]

Helaas is er geen garantie dat de apps van andere banken wel blijven werken. Misschien dat die in de toekomst ook de Integrity API gaan gebruiken en dan heb je weer hetzelfde probleem.

[closefuture]

Het probleem is dat het allemaal steeds lastiger word. Als je bijvoorbeeld een bank in Nederland wilt die niet beurs genoteerd is (i.e. er niet primair in zit voor de aandeelhouders) dan heb je eigenlijk enkel de Rabobank en de Triodos. Alle andere die niet beurs genoteerd zijn zoals ASN en ABN AMRO zijn dat puur omdat ze nu nog van de staat zijn. Opzich zou ik prima naar de Triodos willen maar wie zegt mij dat die morgen niet hetzelfde doen?

[Vaevictis_]

Dit zou moeten werken, er zijn best veel apps die dit gebruiken en ik heb nog geen problemen ondervonden met banken apps. De compatibiliteitslaag is wel vrij goed.

[rustycrab]

Ja dat is altijd de vraag die blijft hangen in mijn achterhoofd. Hoe lang blijft Google GrapheneOS nog accepteren? Waarbij er natuurlijk hoop is dat het gewoon blijft bestaan.

[Polderviking]

Google is al heel lang third party software aan het frustreren met dingen als hun "integrity api", waar je überhaupt niet aan kan meedoen als je alleen software maakt.
Consequentie daarvan is dat er een groeiend aantal apps niet werken, om verder geen enkele concrete technische reden anders dan dat Google bepaald dat jou telefoon niet aan hun betrekkelijk arbitraire voorwaarden voldoet omdat je er Graphene (of iets anders) op hebt gezet.

[Reactie gewijzigd door Polderviking op 13 oktober 2025 13:43]

[evers97]

Tijd dat de EU hier een stokje voor gaat steken want ze belemmeren concurrentie wel heel duidelijk op deze manier

[rustycrab]

Ben ook vaak benieuwd hoe goed zo'n bestuurlijk oorgaan als de EU nou goed door heeft hoe deze bedrijven als Google zonder het officieel zijn van een monopolist toch een monopoly hebben op de markt.

[The Zep Man]

hoe deze bedrijven als Google zonder het officieel zijn van een monopolist toch een monopoly hebben op de markt.

Monopolist zijn is geen factor. Een dominante marktpositie hebben is waarnaar wordt gekeken.

Zowel Apple als Google hebben met hun mobiele besturingssystemen dominante marktposities.

[rustycrab]

Eens. Maar denk dat we wel kunnen vast stellen dat de consument in ieder geval de klos is. Of het nou juridisch wel of niet klopt.

[sympa]

Ik denk dat de specialisten dat best doorhebben, maar dat het lang duurt om met een goede reactie te komen.

Een slechte regelgeving is als een slechte patch, die maakt een probleem alleen maar erger.

[Webxorcist]

De EU wil juist steeds meer meegluren. Ze zullen daarmee vast niet blij zijn met GrapheneOS.

[Cafe Del Mar]

Met "repareerbaarheid" zou je al een eind komen. Nu zijn perfect werkende telefoons (bv Poco F3) niet meer veilig te gebruiken. Als de "repareerbaarheid" zou bestaan uit het gemakkelijk maken van bootloader unlock (cfr Xiaomi restricties) en het draaien van custom ROM's, komen de monopoliepraktijken van Google met hun "integrity API" vanzelf bovendrijven.

[TweakerEend]

Er is geen centrale mening van een "EU". Er zijn genoeg mensen en commisie leden (tot nu toe meerderheid) die tegen chatcontrol zijn, en daarin zijn waarschijnlijk ook een boel die alleen denken dat chatcontrol slechts criminelen zal betrappen en de gewone burger niet zal nadelen.

[wiseger]

GrapheneOS is geen partner van Google. Dus Google sluit ze niet buiten, ze hebben helemaal geen relatie met GrapheneOS.

GrapheneOS werkt samen met een onbekende Google partner die hun stiekem van de beveiligingsupdates voorziet.

[Calypso]

En dat gaat een tijdje goed totdat Google er achter komt wie die partner is; en dat is heel simpel te realiseren door 1 keer een security patch uit te brengen die ergens een watermerk bevat. En dan is die partner het bokkie en is GrapheneOS hun toeleverancier kwijt - en dus effectief gezien buitengesloten.

[Aerophobia1]

Ja die gaan kleine lettertjes vinden of ze overnemen voor een bedrag waar je geen nee tegen zegt..
Daarna de beste ideeen houden, en de rest van bedrijf langzaam de nek omdraaien, zoals grote bedrijven keer op keer doen.

[Kun]

Daar zijn ze al mee bezig, Google heeft nog steeds de broncode van de QPR1 release niet vrijgegeven. In feite is de laatste versie van Android op dit moment dus niet meer open-source.

[kozue]

Open source in Android was altijd al een wassen neus. Wie interesseert het wat dat de kernel open source is, en een paar kleine tooltjes die AOSP meelevert, als het grootste deel van de gemiddelde Android telefoons uit binaire blobs bestaat die je niet kunt verwijderen? Apple en Google zijn allebei net zo veel open source, alleen doet Google net alsof ze daar wel aan doen en Apple niet.

[Elminster]

Apple heeft ook "open-source" code heeft:
https://opensource.apple.com/

Maar daar ga je inderdaad geen OS mee bouwen.

[TweakerEend]

Google heeft baat bij als GrapheneOS doorgaat, omdat ze zeer goed veiligheidswerk doen waarvan Google en Apple ideeen van copieren. Alleen het is een hele rommel binnen Google, ze zouden QPR1 publiceren maar doen dat maar niet zonder uitleg. Dit niveau van onprofessionaliteit laat zien dat er of te veel mensen zijn ontslagen, of bij de management van ingenieurs is goed mis gegaan.

[CH4OS]

Google legt weliswaar geheimhoudingsverplichtingen op, maar toch kan gevoelige beveiligingsinformatie in handen komen van spyware- en malwaremakers.

Wat ook maar een redelijk wassen neus is, nu GrapheneOS eea als binary dus released, hou je toch ook de mogelijkheid tot reverse engineering en kun je toch enigszins zien wat men heeft gedaan om het lek te dichten, of een ander lek te vinden?

[wiseger]

Dat klopt. Het is nu aan Google om te onderzoeken welke OEM fabrikant de Google voorwaarden schent en GrapheneOS van de updates voorziet. Als Google daar uit is, dan zal die OEM fabrikant zijn licentie op Android verliezen en niet langer beveiligingsupdates krijgen.

[RobertMe]

Los van hoe Graphene aan hun updates komt is dit scenario blijkbaar wel afgedekt. Als een lek of (afgeleide) patch geopenbaard wordt zal Google de patch alsnog onmiddellijk openbaren en kan bv Graphene deze patch wel officieel over nemen (in de standaard release dus).

Wat @CH4OS aangeeft is iets dat Graphene laatst letterlijk beschreven heeft. Ze kunnen daadwerkelijk twee keer dezelfde versie uitgeven in binairy vorm, 1x met de patches onder embargo en 1x zonder de patches. Vervolgens kan iedereen (met de juiste kennis) beide versies vergelijken en redelijk precies zien welke code er verschillend is. Om vervolgens een patch te maken die de boel gelijk trekt en deze bij AOSP / Graphene / ... in te dienen. En omdat er dan een openbare (variant van) de patch is zal Google onder hun regels ook het embargo van de specifieke patch(es) die zijn geopenbaard afhalen.
Het enige dat hier dus voor nodig is is dat je als open source ROM fabrikant toegang hebt tot de patches en vervolgens twee versies uitgeven, een met en een zonder patches. En vervolgens wachten tot iemand anders (die liefst niet te dicht bij het project zelf betrokken is ) de boel reverse-engineerd en een eigen patch indient.

[Oon]

En dat is vrij makkelijk te doen door e.e.a. te fingerprinten, zichtbaar én onzichtbaar zodat die fabrikant denkt de fingerprint te kunnen verwijderen maar toch niet blijkt te kunnen.
Niet om ze ideeën te geven, maar erg lastig is het niet.

[latka]

Als Graphene de broncode kan inzien die Google publiceert en die integreert in de eigen build dan zijn fingerprints vrij lastig. Als Graphene 1-op-1 binaries kopieert dan uiteraard wel, maar ik neem aan dat ze iets slimmer zijn dan dat. Als google via source-code fingerprints will uitdelen dan moeten ze voor een security-leak diverse oplossingen maken en die individueel verspreiden. Niet onmogelijk, maar wel arbeidsintentsief (en afhankelijk van de fix valt dit op omdat de oplossing dan de niet meest logische fix is).

[Qin]

Lange adem, je maakt steeds maar 2 versies, iedere keer sluit je 50% uit. Als je meerdere patches per update hebt kun je daarbinnen ook steeds 2 oplossing gebruiken om het veld snel kleiner te maken.

[Niosus]

Dat is wel lastig bij security fixes, waar fixes vaak maar 1 of een paar regels zijn. En de code waar die fixes relevant zijn zit vaak heel doordacht in elkaar. Hoe je daar onzichtbaar entropy gaat inzetten zonder het kapot te maken of zelf nieuwe security issues te gaan veroorzaken...

Fingerprinten werkt goed bij media waar "bijna identiek" even goed is als "identiek". Maar bij code is "bijna identiek" soms gewoon helemaal onbruikbaar.

En de distributie van die patches gaat waarschijnlijk via private repositories. Hoe gaat dat daarmee werken als iedereen die pullt iets anders moet krijgen? Hoe ga je de fingerprint terug uit patches halen die ingestuurd worden zodat je je eigen codebase niet zit onleesbaar te maken?

Ik denk niet dat het zo'n vaart gaat maken. Dan kunnen ze de boel beter closed source maken, als ze dit echt willen tegenhouden.

[Hayland]

Heb je ook bewijs dat ze die voorwaarden schenden?

GrapheneOS werkt namelijk samen met een niet-nader-genoemde fabrikant om een telefoon op de markt te brengen. Het feit dat ze niet vermelden wat die fabrikant is (= "stiekem") betekent niet dat het niet mag.

Developers in dienst van die OEM kunnen in principe toch contributies doen aan een closed source GrapheneOS update?

[Reactie gewijzigd door Hayland op 13 oktober 2025 17:00]

[wiseger]

Het simpele feit dat de OEM de code aan een derde partij geeft terwijl die code nog onder embargo staat, is bewijs voldoende.

Sterker nog, als Google de update in het geheel niet naar AOSP zou brengen, is het ook nog eens een schending van auteursrecht. Het is (nog) geen publieke code.

[Hayland]

Het simpele feit dat de OEM de code aan een derde partij geeft terwijl die code nog onder embargo staat, is bewijs voldoende.

Ben je zeker dat die build (met z'n eigen release track) niet eenvoudigweg op infra van die OEM wordt gebouwd? Dus door ontwikkelaars van die OEM die aan GrapheneOS werken?

[wiseger]

De OEM krijgt de code van google onder licentie. Die mag de OEM dus gebruiken om zijn eigen build mee te fixen.

Wat de OEM doet, is die code ook beschikbaar maken voor een derde partij die geen licentie afneemt bij Google.

Vroeger stond Google dat oogluikend toe, zo kon Graphene er alvast aan werken en waren die klaar voor release zodra de code naar AOSP gebracht werd. Zo werd er tijd gewonnen.

Maar nu wordt het een andere situatie, de code is nog helemaal niet toegevoegd aan AOSP, dus kan de derde partij er helemaal niet over beschikken. Toch brengt de derde partij nu binaries uit op basis van de code waarvoor ze geen licentie hebben.

[Hayland]

Dat beantwoordt mijn vraag helaas niet.

De OEM krijgt de code van google onder licentie. Die mag de OEM dus gebruiken om zijn eigen build mee te fixen.

Ben je zeker dat die ene GrapheneOS build met security updates niet door de OEM wordt gebouwd?

Wat de OEM doet, is die code ook beschikbaar maken voor een derde partij die geen licentie afneemt bij Google.

Het kan best kloppen wat je zegt, maar dat hoeft niet per se zo te zijn. Je bent heel stellig in je claim, vandaar dat ik hoopte op onderbouwing die verder gaat dan onderbuikgevoel.

[wiseger]

GrapheneOS wordt uitgebracht zonder Google copyright claims en service voorwaarden. Ze brengen het uit als open source software.

Een OEM mag geen GrapheneOS binaries bouwen op basis van de gesloten Google Android sources. Google Android is namelijk geen open source, het is gesloten en mag niet gepubliceerd worden en mag zonder licentie niet gebruikt worden. GrapheneOS heeft geen licentie.

Bij elke OEM versie staan daarom ook de copyright claims en de service voorwaarden van Google vermeldt.

[Hayland]

GrapheneOS wordt uitgebracht zonder Google copyright claims en service voorwaarden. Ze brengen het uit als open source software.

Die specifieke build waar we het over hebben wordt uitgebracht als closed source binary. Die is expliciet niet open source.

Een OEM mag geen GrapheneOS binaries bouwen op basis van de gesloten Google Android sources. Google Android is namelijk geen open source, het is gesloten en mag niet gepubliceerd worden en mag zonder licentie niet gebruikt worden. GrapheneOS heeft geen licentie.

Tenzij die OEM toestemming heeft van de GrapheneOS ontwikkelaars, om het tijdelijk closed source te bouwen.

Bij elke OEM versie staan daarom ook de copyright claims en de service voorwaarden van Google vermeldt.

Die bouwen ook Google Play Services en apps in, dus dat is begrijpelijk. Dat zit niet in GrapheneOS. Of vereisen die security patches een afzonderlijke copyright claim?

[Reactie gewijzigd door Hayland op 13 oktober 2025 17:44]

[wiseger]

De OEM kan nimmer toestemming geven aan GrapheneOS. Die toestemming moet komen van de eigenaar van de sources, Google.

Licenties worden nimmer uitgeven als zijnde overdraagbaar op derde partijen. Dus Google gaat een OEM geen licentie geven waarin de OEM toestemming krijgt om de sources uit te delen aan Jan en alleman om op basis van die sources een eigen OS uit te brengen die ze daarna ook nog eens als open source uit brengen.

Zou Google dat wel doen, dan zou maar één OEM een licentie hoeven af te nemen en de rest een dealtje met die OEM kunnen sluiten.

[GertMenkel]

Dat is het punt dat Graphene ook maakt. Zodra de eerste security-update uit is, is het hele embargo nutteloos. Google zou effectief moeten toestaan dat de sources en binaries tegelijkertijd uitkomen, anders heeft het geen nut, maar Google zelf en hun partners willen wel graag wanneer mogelijk hun gebruikers veilig stellen. GrapheneOS zou het liefste zien dat Google teruggaat naar het oude model en de patches weer op de oude manier verspreid.

Het is wel iets makkelijker om op basis van de source code een exploit te schrijven dan op basis van de ge-reverse-egineerde versie, maar als het op malwaremakers aankomt, kun je er wel van uit gaan dat dit weinig toevoegt. Helemaal aangezien partijen als GrapheneOS een stuk sneller zijn met hun security-updates en afhankelijk van de Google-partner dus maanden vooruit lopen op de bedrijven die de boel gesloten willen houden.

[supersnathan94]

Dit is in reactie op het besluit van Google om beveiligingsupdates voor Android voortaan op kwartaalbasis uit te brengen.

Wat een domme zet weer. Een verse zero-day ga je dan gewoon 3 maanden laten zitten? Lekker beleidje weer Google.

Over eigen glazen ingooien gesproken.

[RobertMe]

En dat om de OEMs te "beschermen". Want dan hoeft de OEM niet meer elke maand een nieuwe update uit te geven om klanten tevreden te houden (als in: "waarom heb ik in oktober de secutity updates tot juli en niet september?").

Maar..., OEMs die het wel goed doen mogen weer wel gewoon updates uitgeven met deze patches. Dus een fabrikant die wel altijd netjes ~elke maand een update uitgaf met de laatste security updates kan dat nu nog steeds. Enige voorwaarde is dan dat ze de patch niet mogen publiceren. Maar puur een gecompileerd image uitgeven mag wel. (En dat is dus ook wat Graphene gaat doen. Eerst alleen als binary uitgeven en pas na vervallen van het embargo de patch toepassen op de open source repository).

[supersnathan94]

Enige voorwaarde is dan dat ze de patch niet mogen publiceren. Maar puur een gecompileerd image uitgeven mag wel. (En dat is dus ook wat Graphene gaat doen. Eerst alleen als binary uitgeven en pas na vervallen van het embargo de patch toepassen op de open source repository).

Met alle risico's van dien. Het punt van OSS is juist dat je die audit fatsoenlijk kunt doen.

[roflpantoffel]

Aan de ene kant roept Google dus dat ze onder het mom van veiligheid Android steeds meer moeten dicht timmeren en aan de andere kant zorgen ze er bewust voor dat beveiligingsproblemen later kunnen worden opgelost.

Volgens mij kan de EU met DMA hier goed een stokje voor steken, zodat er iig voor europeanen een open Android platform blijft bestaan.

[wiseger]

Nope dat kan niet. DMA heeft hier niets mee te maken. De DMA is van toepassing op Google Android. Maar GrapheneOS heeft niets met Google Android te maken. GrapheneOS is gebaseerd op AOSP Android.

Achter GrapheneOS zit maar een kleine organisatie die niet in staat is zelf beveilingsupdates uit te brengen.

Dus halen ze een truuk uit. Een onbekende Google Android OEM leverancier voorziet GrapheneOS illegaal van de security updates die voor Google Android uitkomen onder embargo. GrapeheOS gebruikt die updates om er security updates voor hun AOSP versie van te maken. En deze vervolgens vroegtijdig te releasen.

[TweakerEend]

Ik denk niet dat de code die de OEM levert aan Graphene illegaal is, aangezien ze partners zijn.

[wiseger]

Uiteraard is het illegaal. De OEM heeft een overeenkomst met Google en is daarmee akkoord met het embargo gegaan die in de overeenkomst staat. Als ze dan toch stiekem het embargo omzeilen en GrapheneOS de code eerder levert, dan is dan tegen een overeenkomst die de OEM met Google heeft gesloten.

[TweakerEend]

Our OEM partner will be asking whether they're allowed to publish the sources for new major Android releases on the official launch date. If they're allowed to publish it then we don't need to depend on AOSP. The AOSP delay is supposedly not intended so this should be a solution.

Link

GrapheneOS zou niet zomaar tegen de spelregels ingaan, omdat ze anders teveel riskeren en ze publiekelijk de illegale monopoly praktijken van Google ook afkeuren. Ik zie ook geen reden waarom Google geen toestemming zou geven aan de OEM om de code met GrapheneOS te delen.

[wiseger]

Ze zeggen dat de OEM gaat vragen of die toch de code al eerder weg mogen geven. Iets gaan vragen is iets heel anders dan het reeds doen.

Er zit een embargo op de code de de OEM van Google ontvangnt. Echter de OEM geeft de code toch alvast aan GrapheneOS, een derde partij.

Dat is een embargo schending. Ondanks dat GrapheneOS stelt zelf de code nog niet verder te publiceren.

Om de geheimhoudingsverplichting niet te schenden, brengt GrapheneOS de beveiligingsupdates uit als binaire releases. Openbaar maken van de broncode mag pas zodra Google de Android-updates officieel uitbrengt voor het Android Open Source Project (AOSP).

Het is nu afwachten op de reactie van Google. Ik zou ze groot gelijk geven als ze de OEM eruit zouden gooien wegens het schenden van het embargo.

[TweakerEend]

De embargo is toch wel over dat je de code niet publiek mag maken. OEM maakt de code niet publiek door het te geven aan GrapheneOS. GrapheneOS is open source, maar ze hebben gezegd dat ze de veiligheidscodes waarop een embargo staat niet zullen publiceren. Alles lijkt op orde. Als Google hier toch een probleem gaat maken is dat heel kortzichtig en suf van hun, maar ik denk dat ze daar sowieso niet aan toe zijn, ze hebben moeite met het publiceren van QPR1 wat een maand geleden had moeten plaatsvinden.

[wiseger]

GrapheneOS is een derde partij die geen OEM overeenkomst heeft met google, Daarmee overtreed de OEM het embargo. Het is nu afwachten of Google in actie gaat komen tegen deze OEM.

Google hoeft geen QPR1 te publiceren. Google mag QPR1 publiceren.

Google is de eigenaar van Android. AOSP is het open source project. Dat AOSP inmiddels compleet afhankelijk is van Google om dat andere partijen waaronder GrapheneOS praktisch niets bijdragen, is niet het probleem van Google.

[A11ert]

Soms hoop ik echt dat er een goede Linux Mobile variant komt die ook op moderne mobiele telefoons ondersteund wordt.


Want Google begint steeds meer op Apple te lijken.

[M3m3nt0m0r1]

Wat heeft Apple hier mee van doen?

[rvdv12773]

Ik neem aan dat hij het dichttimmeren van het OS bedoeld, en het op die manier zo goed als onmogelijk wordt gemaakt om custom-roms te draaien, of het OS op welke manier dan ook te customizen. Apple loopt daarin voorop, en sommige power-users vinden dat niet prettig...

[TweakerEend]

Linux Mobile bestaat al, en dat is Android.

Een competitie tegen Android zie ik niet aankomen. Android op zich is een heel fatsoenlijk OS. Binnen Google en VS is er nog van alles gaande met veel destabiliserende factoren en rechtzaken, hopelijk komt het goed.

[Mr.Monk]

ik dacht ik kijk even wat het is. Maar is alleen voor Pixel telefoons helaas.

https://grapheneos.org/faq#supported-devices

[ocarina]

Een custom rom die minder hard is op security maar nog wel een redelijke privacyfocus heeft (microG ipv Play Services, alternatieve apps voor google dingen) is /e/OS. Die ondersteunen heel wat meer toestellen.

[TweakerEend]

Het is inderdaad alleen voor Pixels omdat de niveau van kwaliteit erg hoog is (van Pixel hardware en software ondersteuning). Geen andere custom OS komt dichtbij wat GrapheneOS aanbied in het gebied van veiligheid en privacy. Toch mooi dat er uberhaupt een telefoon model is waar dit op kan.

[Vexxon]

Zo open is Android dus allang niet meer, Google doet er alles aan om dit soort initiatieven tegen te werken.

Don’t be evil...

[wiseger]

Je moet onderscheid maken tussen Google Android en AOSP Android.

[kuurtjes]

Wat ik me afvraag is of het niet tegen de DSA ingaat.

[CH4OS]

Hoezo zou het tegen de Digital Services Act in gaan dan? Ik neem aan dat je de DMA bedoelt, maar ook dat doet eigenlijk niet ter sprake, GrapheneOS is geen poortwachter immers.

[kuurtjes]

Maar Google is met Android wel een poortwachter. En het zijn zij juist die alles buiten Android proberen tegen te zitten.

[CH4OS]

Google Android is dan weer niet hetzelfde als AOSP Android, waarop GrapheneOS gebaseerd is.

[Pyronick]

Hot take: het probleem is niet alleen Play Services, maar het hele Android-framework zelf. Zolang je Activities/Intents en de hele Binder-kermis target, blijf je in Google’s ecosysteem hangen, microG of niet. Ondertussen is Linux gewoon volwassen: stabiele ABI (op wat glibc-kuren na, vandaar dat ik de GNU/-prefix niet noem ), systemd overal (wat je er ook van vindt), Wayland bruikbaar (nVidia is sloom, maar komt op stoom maar voorlopig ook irrelevant in mobile), dependency hell passé. En “het jaar van de desktop”? Dat ligt achter überhaupt ons; we leven in de mobile connected-era van phones, wearables, narrowcasting, TV’s en PWA’s.

Wat mij betreft is de stap voor ons tweakers helder: trek die oude telefoon uit de la, ga spelen met postmarketOS, UBports, whatever, zet Flatpak voorop en demp de pijn met Waydroid voor die paar must-have apps, of gebruik tijdelijk GrapheneOS als tussenstap. Ja, Android/iOS “just works”, maar iets wordt pas alternatief als we het gebruiken, meten en terugkoppelen. Kijk naar standby-verbruik, VoLTE/VoWiFi en notificaties, en deel je resultaten. Schrap desnoods iedere maand één Android-app: kleine stapjes, grote impact. Minder profeteren over “het jaar van X”, meer flashen in het weekend. Soevereiniteit en levensduur krijg je niet cadeau, die bouw je.

[Reactie gewijzigd door Pyronick op 13 oktober 2025 14:16]

[IamGrimm]

Ondertussen vraagt m'n schoonmoeder waarom haar telefoon weer vol zit.

Soevereiniteit en levensduur dwing je af door wet en regelgeving. Bouwen doe je in je eigen tijd.

[Pyronick]

Soevereiniteit en levensduur dwing je af door wet en regelgeving.

Mee eens, maar in Europa blijkt steeds vaker dat wet- en regelgeving de finishvlag is, niet het startpistool.

Beleid volgt bewijs. Big Tech zet de hakken in het zand (zie o.a. hun houding t.o.v. de DMA), en politici bewegen pas als er meetbare alternatieven en grassroots-momentum zijn. Dat is precies waar tweakers het verschil maken: rommelen, ritselen, meten, terugkoppelen, pull requests, mergen, etc.

Je schoonmoeders ‘telefoon vol’ los je niet op met een opiniestuk (daar staan de kranten immers vol mee), maar inderdaad via beleid, en dat beleid komt alleen door werkende voorbeelden. Dus ja: bouwen doe je in je eigen tijd. Die wetgeving komt er nooit, tenzij er voorbeelden zijn.

[TweakerEend]

De alternatieve Linux Mobile OS'en die je noemt hebben zo goed als 0 veiligheid en zijn veel minder gebruiksonvriendelijk en heb je veel compatibiliteitsissues. Misschien leuk als een hobby om te koekeloeren, maar gebruiken als een dailydriver? Veel success.

[Pyronick]

Juist daarom zijn ze nu voor tweakers, niet voor je oma. 😉

Zonder de gebroeders Wright immers geen Boeing, zonder Linus geen Linux, zonder Paulus geen Home Assistant. Iemand moet de rommelige beginfase doen!

[questarey]

Ik kreeg gister deze melding voor de snellere updates, maar ik vind die updates altijd zo traag dat ik ze liever uitstel. Ik doel hier op het 'optimizing apps' proces wat er na de reboot gebeurd.

En Graphene gooit echt elke week updates eruit.. Hopelijk nu niet meer :P

[TweakerEend]

Ik vind de updates soms ook hinderlijk maar dan weet je wel dat de OS je draait echt up to date en veilig is.