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 (121)

[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.

[dimdek]

Het grote probleem is dat de EU vrijwel uitsluitend handelt op input van lobbyisten en die worden betaald door de Big Tech bedrijven. Daardoor is de mening van alternatieve systemen zwaar ondervertegenwoordigd en kunnen Big Tech bedrijven hun posities blijven versterken. Zelf de onderzoeken worden gesponsord door Big Tech en dan is de uitkomst wel te raden.

[De_Daapse]

Vol met wat?

[morphje]

Android is in de basis nog ook altijd Linux. Ja ik snap dat er vele nuances zijn, maar ik wil het hebben over je hot take.

Want waar draaien die linux varianten die je noemt met name op? Oude hardware of hardware waar de drivers van beschikbaar zijn. Precies dezelfde hardware waar vele android roms voor beschikbaar zijn. Ik vind het prachtig dat initiatieven als UBPorts bestaan, maar zonder een fatsoenlijk hardware platform is dat over.

Nu Google als een van de laatste grote spelers de drivers voor AOSP heeft teruggetrokken voor de pixels in de laatste Android versie, is het einde ingezet. Alleen nog maar kleine niche hardware leveranciers kunnen dan nog toestellen leveren die compatible zijn. En hoe lang duurt dat nog? Ook die hardware leveranciers (fairphone, pinephone, volla) zijn afhankelijk van chipleveranciers. En wie heeft daar de grootste macht? Google.

De lijst van support devices wordt per jaar steeds korter en korter. Dus het is leuk dat Linux initiatieven bestaan, maar net zo zeer als Android alternatieven zijn ze afhankelijk van hardware. En afdwingen dat je op je eigen hardware mag installeren wat je wilt is een uphill battle. Vooral gezien de houding over chatcontrol.

[Pyronick]

Je punten zijn allemaal valide, maar missen mijn punt: het gaat niet om “Android = Linux”, het gaat om macht over de stack. Wie de drivers, de bootketen, certificering en integratiecontrole in handen heeft, wint. Zolang Google en OEM’s die kranen dicht hebben, kunnen ze morgen geruisloos van Linux naar Fuchsia overstappen zonder dat de gebruiker het merkt. De “Linux”-badge is dan zo relevant als zeggen dat macOS op “BSD” leunt, leuk voor de pubquiz, waardeloos voor autonomie.

Dat hardware de bottleneck is, daar ben ik het volledig mee eens, en precies daarom moet je dáár openbreken in plaats van alternatieven weg te wuiven omdat ze vandaag nog ruw zijn. Zonder alternatief geen hefboom richting wetgever of inkoper. Wat een wetgever én/of OEM wel kan doen: de bootloader moet officieel en herstelbaar ontgrendeld kunnen worden (zoals Fairphone momenteel), zodat mensen kunnen hacken, reverse engineeren en verbeteren, precies het soort werk dat bewust maar onterecht wordt ondergewaardeerd. Laat publieke inkopers bovendien een deel van hun toestellen kopen op basis van een open device-baseline (nu bepalen Amerikaanse standaarden de normering en certificering; wij moeten een eigen, capabele Beveiligingsautoriteit inrichten), dan krijgen niche-leveranciers (Fairphone, HMD, etc) schaal en hebben chipmakers eindelijk een prikkel om mee te bewegen. Ondertussen lijkt de Europese industrie een Nokia 2.0, 3.0 en straks 4.0 te laten gebeuren (zoals Apple Nokia voorbijvloog met de iPhone), omdat we blijven consumeren in plaats van de open!! stack te claimen.

Ja, de lijst met “compatibele” devices krimpt. Dat is geen natuurwet, het is het symptoom van lock-in die we zelf in stand houden. Alternatieven, hoe onaf ook, zijn geen einddoel maar onderhandelingsmacht. En nog iets: Linux wordt hier misbruikt om z’n open-source karakter, anders hadden ze net als Apple, Sony en co gewoon voor een *BSD-afgeleide gekozen. Het probleem is dus niet of Android “op Linux” draait, het probleem is dat “Linux” als etiket een gesloten keten moet legitimeren. Open die keten bij de hardware, en de rest volgt. En kijk naar de Chinezen: daar bouwen ze een eigen OS (HarmonyOS, EulerOS, AR OS) met een eigen stack, feitelijk een Android 2.0 met alle minpunten die ik noem, maar ze doen het wél.

[morphje]

Ja, geheel mee eens.

Maar je blijft herhalen dat "wij" de gebruikers onze hardware onder controle moeten nemen en dat wetgeving zal volgen. Mijn claim is dat dat niet gaat gebeuren. Want we hadden en namen de afgeloppen 10 jaar de controle over onze eigen hardware. Hoe lang moeten we dat dan doen om uiteindelijk die wetgeving te krijgen?

Met wetsvoorstellen als chatcontrol en het expliciete vertrouwen van banken (al dan niet met ondersteuning/dwang van de EU) in de iOS/Android ecosystemen zal dat simpelweg niet veranderen. Tel daarbij ook de talloze anti-encryptiewetten op en het plaatje is compleet. Het probleem zit niet bij ons, de tweaker, maar bij de wetsmakers/beleidsuitvoerders. Die zijn ziende blind (al dan niet bewust), zelfs Duitsland, privacy voorvechter nummer 1, heeft zich meermaals ingelaten met diezelfde anti-consumenten wetten.

Wij, de tweaker, hebben simpelweg niet het lobbyapparaat om in contact te komen met de juiste mensen. Wat we nu effectief doen is protesteren op het malieveld met 100 man, 3 vlaggen en een stapeltje petitieflyers. Niemand die er wat om geeft en niemand die er wat aan gaat doen. Dat is ook de harde realiteit (hoewel ik het persoonlijk uiteraard anders had gezien) en geen enkel ecosysteem gaat daar iets aan veranderen, linux, aosp of van mijn part MSDOS.

Waar ik rekening mee hou is een toekomst waarbij ik een google heb voor bankzaken die thuis ligt en voor het bellen gewoon weer een ouderwetse featurephone ga gebruiken. Voor de rest heb ik pasjes. Ik heb vandaag m'n auto verkocht aan een sloper en die vond dat ik maar de digid app moest installeren zodat het voor HEM sneller ging. Ik heb geknikt, ja en amen gezegd, maar helaas nu eventjes niet.

[Pyronick]

Mijn claim is dat dat niet gaat gebeuren.

Dat is inderdaad de nuchtere, realistische kijk, maar ik denk dat je onderschat hoezeer het speelveld aan het kantelen is. Chat Control is uitgesteld, niet alleen dankzij activisten maar ook door weerstand van parlementen, juristen en toezichthouders. Er komt besef dat technologische autonomie een veiligheidsbelang is, en als de European Digital Identity (gebaseerd op W3C Verifiable Credentials) goed wordt uitgerold, kan dat de vermeende “noodzaak” van Chat Control zelfs grotendeels wegnemen.

De digitale euro (hoe verwaterd ook, met Amazon op de achtergrond) is daar een voorbeeld van: geïnspireerd door het succes van Brazilië’s Pix, bedoeld als tegenwicht tegen onze eigen grootbanken én om minder afhankelijk te zijn van private infrastructuren als Visa, Apple Pay en Google Pay.

Het idee van Public Money, Public Code begint langzaam wortel te schieten. Terwijl het Ministerie van Microsoft (SLM Rijk) verdacht pusht om alles naar Azure en 365 te tillen, groeit tegelijk een tegentrend: FOSS-impulsen via Horizon Europe, het Sovereign Tech Fund en initiatieven als GrapheneOS, Proton en Nextcloud.

Het verandert niet morgen, maar de grond is aan het schuiven.

Niemand die er wat om geeft en niemand die er wat aan gaat doen.

Wij niet, maar politici kunnen dat wel.

Ik weet heus wel dat veel van wat ik zeg wensdenken is. Maar zolang we in Nederland in die defaitistische modus blijven en niet meer kritisch blijven klagen en klakkeloos accepteren, zakt het land langzaam weg in zelfgenoegzaamheid. Juist daarom waardeer ik jouw anekdote over die autoverkoop, omdat ze laat zien dat het ook anders kan. Brutale mensen hebben immers de halve wereld, soms moet je ook een beetje brutaal durven zijn, denk ik dan.

[morphje]

Oh met dat laatste heb je zeker een punt. Ik blijf vechten, maar ik accepteer tegelijkertijd een lot waarbij ik veel comfort moet opgeven. Liever geen comfort van een vrije smartphone als dat betekend dat ik vrijheid krijg, dan dat ik gevangen ben door mijn telefoon.

Ik denk dat ik wel een leuke parallel heb voor onze diep ingebakken defaitistische karakter. We geven toe aan druk, we durven niet stil te staan en het schip te keren. Het mooiste voorbeeld daarvoor is onze eeuwige energie crisis. Van een oliecrisis in de jaren 70, rolde we door naar een bloedkolen crisis, die kolencrisis werdt een milieucrisis. Nu hebben we net een aardgas crisis achter de rug, maar stormen we nu af op een duurzame energie crisis. De oplossing is simpel: bouw die kerncentrales, maar geen enkel kabinet durft die lange termijn verantwoordelijkheid aan. Frankrijk heeft bewezen dat het de oplossing was. Mede dankzij de kerncentrales van Frankrijk werd de rest van Europa niet meetrokken in de blackout van Spanje.

En zo weer terug naar de digitale euro, digitale identiteit, chatcontrol. Het zijn allemaal wetgevingen en middelen die maar 1 doel hebben. Het doel is bepaald en daar moeten we naar toe, op welke manier dan ook, ongeacht de implicaties, ondanks de zwarte geschiedenis die europa heeft met dit soort middelen. (lees: gemeentelijke registratie van religie tijden WW2). Denk ik dat het speelveld aan het veranderen is? Ik zou het willen geloven, maar de langdurige geschiedenis doet me helaas somber stemmen. Er wat mij betreft nog veel meer nodig dan dit beetje tegengas.

En ja, liever 100 verschillende stekkertjes voor m'n mobiele telefoon dan een privacy schendend monster dat telkens z'n lelijke hoofd opsteekt.

[Pyronick]

Ik moet zeggen dat ik juist meer fiducie heb gekregen dankzij de Europese Unie, die ons in mijn ogen "beschermt" tegen de nukken van Den Haag, zoals Den Haag ons vaak weer beschermt tegen Brussel, Berlijn en Parijs. Zo ontstaat er toch een soort van scheiding der machten, een trias Europeana als het ware. De EU is immers ooit opgericht met het doel om nooit meer WO2-achtige taferelen te krijgen.

Veel Europese en post-WO2 wet- en regelgeving hebben juist meer transparantie en openheid gebracht. Natuurlijk gingen daar vaak vervelende compromissen mee gepaard, meestal financieel "gelukkig", en niet op het vlak van privacy of rechtsbescherming. Maar het feit dat zoveel nationale regeringen samen moeten werken, dwingt nu eenmaal tot openheid.

Wat jij zegt over de zwarte geschiedenis in Europa met dergelijke middelen herken ik wel (zeker met de meer conservatieve koers van commissies zoals die van Von der Leyen). Daar schuilt inderdaad het risico dat plannen als Chat Control erdoorheen glippen. Vooral omdat we op precies dat vlak zien hoe snel het in post-Brexit Verenigd Koninkrijk mis kan gaan als checks and balances (de "trias Europeana") verdwijnen. Gelukkig loopt Nederland in sommige opzichten voorop, met projecten als yivi/IRMA, die laten zien dat identificatie ook privacyvriendelijk kan. Want het alternatief zal hoogstwaarschijnlijk alleen maar méér privacyonvriendelijk zijn.

Toch blijft het oppassen. De politieke wind kan zo draaien dat zulke initiatieven uiteindelijk verwateren tot iets waar je je hele digitale hebben en houwen moet blootgeven. Dat is precies waarom we niet mogen afhaken, maar kritisch en luidruchtig moeten blijven.

[TweakerEend]

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

[Reactie gewijzigd door TweakerEend op 14 oktober 2025 03:05]

[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!

[jurroen]

Laten we even eerlijk zijn: Linux zit allang niet meer in de beginfase. En als Tweaker vind ik het geweldig om te spelen met allerlei meuk - maar mijn belijzer moet gewoon werken. Ik moet ervan aan kunnen dat anderen mij kunnen bereiken als ze mij nodig hebben, dat ik niet met een crashende launcher zit of een driver die niet goed initialiseert.

Met GrapheneOS heb ik die zekerheid. Het is veilig en stuurt mijn data niet naar een wolkje, naar gebakken lucht van een derde partij.

Met PostmarketOS, UBports en dergelijken heb ik die garantie niet. Sterker nog, een van de PMOS developers bewaart zijn signing keys onbeschermd op zijn Windows gaming PC. Lekker veilige gedachte

[arjankoole]

Dit. Met daily drivers gaan we niet lopen experimenteren. Ik moet er niet aan denken dat ik iets aan de primaire devices mol.

[CAPSLOCK2000]

Dit. Met daily drivers gaan we niet lopen experimenteren. Ik moet er niet aan denken dat ik iets aan de primaire devices mol.

Beetje OT, maar dat is waarom we backups maken.

Je telefoon kan op ieder moment zomaar stuk gaan (net als ieder ander apparaat). Als je huiverig bent over het herinstalleren van je telefoon of het terugzetten van data zou je het eigenlijk regelmatig moeten oefenen. Zeker als je in het alternatieve circuit zit en de backups van Google niet kan/wil gebruiken.

Ik weet het, het is makkelijker gezegd dan gedaan, maar ik denk dat we (de maatschappij) meer aandacht moeten gaan geven aan waar onze data staat, hoe die beveiligd is, hoe we er zelf wel bij komen en wat we doen in noodgevallen. De meesten vertrouwen nu blind op Google en Apple. Hoewel dat meestal goed gaat is het wel riskant, we zijn enorm afhankelijk van dat ene apparaat en die ene account.

[PureTryOut]

Hey, postmarketOS developer hier. Los van wat je vind van ons project, "signing keys onbeschermd op zijn Windows gaming PC" vind ik nogal een beschuldiging waar ik ons team niet in herken. Heb je een bron voor mij?

[jurroen]

Hey - dankjewel voor je reactie. Daar heb ik zeker een bron van. Ik DM je morgen (dit is niet iets om en plein public te doen, IMHO).

[Nark0tiX]

Minder gebruiksonvriendelijk? Gebruiksvriendelijk dus.

[readefries]

Heb je UBports al eens geprobeerd? Ik heb nu Graphene op mijn pixel 8a, maar wil het eigenlijk wel proberen. Al is het nog wel een klusje om zelf een port te maken zag ik.

[Pyronick]

Vorig jaar draaide ik nog Ubuntu Touch op een oude, afgedankte Poco X3. Die ligt vast nog ergens in een la.

Helaas wel op een sterk verouderde Linux kernel...

[sanscorp]

Hier een adopter van CRdroid op de poco f1 die ik als daily gebruikte. Maar heb ook gehad dat op belangrijke momenten de dialer mij in de steek liet. Dan ben je bereikbaar en hoor/voel je de telefoon overgaan maar kan je niet opnemen.

Of een update die fout gaat en je toestel start niet meer op. Kan je alles via je PC weer gaan flashen.

Ja ik ben er voorstander van, nee het is echt niet voor iedereen en ook niet voor een daily.

[Reactie gewijzigd door sanscorp op 14 oktober 2025 05:53]

[Pyronick]

Dat begrijp ik helemaal. Voor daily use is bleeding edge helaas verre van ideaal, tenzij je het niet erg vindt om met twee toestellen rond te lopen.

Mijn dagelijkse telefoon is helaas een Samsung Galaxy S20 met Android, maar dat is nu eenmaal een opgelegde corporate policy.

[d3x]

kom nog eens terug als je ECHT niet meer weet wat te doen elke avond na het werk en in het weekend en je dan constant tot in de **** gaat prullen voor iets dat ondertussen je dagelijkse gebruik is....

security begint bij jezelf, als dat je doel is, dat blijken velen steeds te vergeten. idem trouwens aan online identity.

[Teun!]

Als iemand met een Pinephone, ik vond toendertijd de software van vele distrubuties ondermaats (voor een telefoon, pc laat ik buiten beschouwing). Slecht battery life, telefoongesprekken komen niet altijd door, etc. Is dit ondertussen al verbeterd? Battery life was echt een paar uur (en ik kom regelmatig op mijn P8Pro al batterijduur te kort).

Dus ik heb helaas nog niet 1 van deze syatemen als ECHT alternatief kunnen zien.

[Pyronick]

Veel daarvan is helaas nog steeds ondermaats, vooral de batterijduur. De belangrijkste optimalisaties die Android zo zuinig maken, zitten diep in de binder-architectuur en in Google’s aangepaste kernel-patches. Die verbeteringen zijn nooit echt upstream gegaan naar de standaard GNU- of musl-stacks, waardoor mobiele Linux-distributies structureel achterblijven op energiebeheer.

Het bellen is inmiddels wél flink verbeterd, met name onder Phosh en Plasma Mobile. Er is nog steeds volop ontwikkeling gaande, niet alleen in PipeWire, Wayland en de Gtk/Qt-frameworks, waar de nadruk nog steeds op desktop ligt, maar ook in allerlei services en daemons die achterhaald waren of speciaal vanaf nul voor telefoongebruik gebouwd moesten worden. De Android-diensten zijn immers niet één op één bruikbaar op een regulier GNU/Linux-systeem.

Maar echte alternatieven met feature parity en dezelfde quality-of-life van een moderne iPhone of Android zijn er nog niet...

[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.

[locke960]

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).

En dat is dus raar, want:

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.

Dus wat er gebeurt: De snelle OEM brengt een binary patch uit. De patch wordt binnen een paar uur door het kwade volk geanalyseerd en binnen 24 uur is er een exploit die ze dan nog 2 maanden kunnen gebruiken op toestellen van andere OEMs. Ondertussen weten de gebruikers van die toestellen niet eens dat er een kwetsbaarheid is en kunnen ze ook geen alternatieve maatregelen nemen.

Ik ga er blind vanuit dat de NSA, bedrijven als de NSO group, en de georganiseerde misdaad hiervoor geautomatiseerde processen hebben ingericht.

Met ander woorden, het is schijnveiligheid, er wordt niets bereikt.

[Teun!]

Dit is natuurlijk de schuld van de OEMs. Wat is het alternatief? Niks patchen en iedereen maar uitgebuit laten worden? Of denk jij dat die exploits anders niet gevonden zouden worden? Ik ga er vanuit dat er al partijen zijn die deze exploits gebruiken/klaar hebben liggen.

[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

[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.

[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?

[readefries]

Op zich zou dat zo kunnen, alleen heeft Triodos dat teruggedraaid nadat mensen die GraphenOS gebruiken daarover klaagden. Op GitHub geeft een van ontwikkelaars aan dat ie nu een toestel heeft met GrapheneOS om het ook te kunnen testen.

[Teun!]

Super bedankt hiervoor, dit laat mij overwegen om van bank te wisselen (mijn bank SNS heeft mij verteld dat ze de huidige nfc betalen app in leven zouden laten naast de google pay app, maar na overname hebben ze die app toch laten vallen).

[readefries]

Graag gedaan, ondanks eigen belang 😄

Oh ja, dan ben je dat voordeel ook kwijt. Ik vind het jammer dat banken zoveel weg geven aan Google, had het wel fijn gevonden als het betalen gewoon zonder Google kon.

[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.

[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.

[netmeester]

Had het artikel destijds ook gelezen en begon al bezorgd te worden. Maar:
Ik heb de Rabo-app nog steeds gewoon draaien op GrapheneOS en gebruik die ook regelmatig. Werkt prima. De app zie ik ook nog staan in de play store (via Aurora).

Toegegeven, ik durf die app nu niet zonder meer te updaten maar ik ondervind geen problemen met betalingen. Ik wacht nog even verdere berichtgeving af voordat ik ga updaten.

[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.

[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.

[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.

[keuringsdienst]

Bij EU gaan dat soort zaken altijd lang duren, door tegenlobby werk. Voor een bedrijf dat ooit begon met "don't be evil", zitten ze nu wel echt aan de verkeerde kan van goed & kwaad door beveiliging te frustreren.

[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.

[Annihilism]

De meeste landen waren voor chat control.. Er was een kleine blokkerende minderheid. Daarnaast wordt in veel landen het hebben van een pixel telefoon al als verdacht gezien (zoek maar eens op spanje + pixel).

[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.

[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.

[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.

Edit: I stand corrected :-)

[Reactie gewijzigd door ocarina op 14 oktober 2025 16:58]

[Matthijs8]

MicroG draait net als de standaard Play services met systeemrechten, in tegenstelling tot de gesandboxde Play services bij GrapheneOS die niet meer rechten heeft dan elke andere gesandboxde app. Je kunt deze ook altijd nog in 1 profiel of in de private space installeren, zodat de rest vrij is van Play services.
MicroG download ook nog weer eens closed source binary blobs, dus is niet zo open-source als ze doen voorkomen.
e/OS loopt niet alleen ver achter op security updates voor Android, maar ook voor Chromium. En die wordt ook als webview door veel andere apps gebruikt, dus een andere browser installeren lost dat niet op.
En in tegenstelling tot stock Android/iOS waar voice-to-text lokaal verwerkt kan worden, stuur e/OS je audio rechtstreeks naar openAI.
https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

[Reactie gewijzigd door Matthijs8 op 14 oktober 2025 14:24]

[ocarina]

e/OS loopt niet alleen ver achter op security updates voor Android

Het is nog altijd beter dan de oorspronkelijke rom op mijn telefoon die zn ondersteuning is verloren in 2021

Beveiligingsupdates zijn van 1 september dit jaar volgens mijn toestel, dus dat lijkt me redelijk. Ik kan zogauw niet zien hoe het zit met Chromium. Ik heb echter ook wel eens ergens gelezen dat niet elke patch gereleased wordt voor /e/OS.

En in tegenstelling tot stock Android/iOS waar voice-to-text lokaal verwerkt kan worden, stuur e/OS je audio rechtstreeks naar openAI.

Dit vind ik wel shocking. Ik gebruik heel Murena niet (en speech-to-text ook niet), ik heb mijn telefoon gekoppeld aan Nextcloud, maar het gaat in tegen zowat alles waar ze voor zeggen te staan. Gezien de redenen waarom de gemiddelde gebruiker hun OS toepast is het logischer om concessies te doen op de kwaliteit van de omgezette tekst.

Helaas zijn er ook niet zoveel alternatieven. Calyx schijnt goed te zijn maar blijft telefoons niet zo lang ondersteunen. Mijn toestel heeft daar nooit ondersteuning voor gehad. Het is in ieder geval beter dan alle data aan Google geven.

[Matthijs8]

Bijna elke Chrome/Chromium update tegenwoordig heeft wel een of meerdere security patches. LineageOS is zowel met Chromium als Android sneller met patchen en brengt vaker updates uit:
https://infosec.exchange/@divested/112815308307602739
https://eylenburg.github.io/android_comparison.htm

Met een EOL device kan je overigens nooit volledige security updates krijgen, omdat er dan geen vendor specifieke firmware updates voor hardware onderdelen meer zijn. En alleen bij de maandelijkse security patches heb je zelfs nog minder, omdat dat alleen backports van High en Critical vulnerabilities zijn. Voor Medium en Low heb je de laatste Quarterly/Monthly AOSP nodig. (Al is dat nu met het veranderde beleid waarschijnlijk alleen de Quarterly.
En ik begreep dat e/OS vaker bepaalde patchlevels claimed terwijl ze niet daarvan alle patches geïmplementeerd hebben..
En dan zit je er ook nog mee dat veel oudere devices vastzitten aan een EOL versie van de Linux kernel, waardoor je nog met allerlei kernel vulnerabilities zit.
Veel alternatieven zijn er inderdaad helaas niet. Ik heb zelf goedkoop een Pixel gescoord om GrapheneOS te kunnen draaien. Dat was een 8a, maar sommige oudere Pixels hebben ook nog een aantal jaar officiële ondersteuning.

[Reactie gewijzigd door Matthijs8 op 15 oktober 2025 20:45]

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[Hayland]

Je gaat er van uit dat alle GrapheneOS ontwikkelaars bij die tijdelijk gesloten broncode kan. Ik heb nog niks gezien waar dat uit blijkt.

Zoals ik aangaf kan het ook zijn dat de OEM zelf ontwikkelaars heeft die de closed source GrapheneOS build bouwen.

Beide is speculeren, tot iemand aantoont welk scenario het is.

[wiseger]

Het scenario doet er niet toe, een OEM mag geen binaries bouwen op basis van Google code en die aan andere bedrijven doneren. Die de binaries vervolgens distribueren in notabene een OS dat met Google concurreert. Waarbij ook nog eens de copyright claim van Google verwijderd is.

Je begrijpt het probleem niet, als Google de code niet onderbrengt bij AOSP mag Graphene de code nimmer gebruiken. Ook niet in gecompileerde vorm. De code is namelijk geen open source maar valt onder het intellectuele eigendomsrecht van Google.

[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.

[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...

[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.

[wiseger]

Je moet onderscheid maken tussen Google Android en AOSP Android.

[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...

[L0g0ff]

Dat Apple alles default gesloten uitbrengt terwijl er tot voor kort altijd een actuele Android opensource variant bestond (AOSP = Android Open Source Project).

Nu Google ook naar een meer gesloten model toe aan het bewegen is gaat het dus steeds meer op Apple lijken.

[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.

[A11ert]

Android kan ik niet geheel Linux noemen. Het is wel gebaseerd op Linux.

Voor de rest zijn er al een paar Linux varianten voor mobiel als "Ubuntu Touch" en "PostmarketOS"

[ronnySB]

Het punt van de automatische updates is dat je nu helemaal geen controle meer hebt over je eigen telefoon. Als de EU besluit bepaalde functies niet meer te willen, bijvoorbeeld nieuws of APPs uit Rusland, waar iedereen recht op heeft, kan zij Google opdracht geven deze functie uit te schakelen in android. Met andere woorden, je telefoon is niet meer van jezelf. Je verliest het vrije gebruik van je telefoon. Als je die al had;-)