Catch-22.

Google verwijst door naar de fabrikanten en telco's.
Voor hen is het alleen maar een kostenpost, dus lage prio.

Van de overheid heb je ook weinig te verwachten, want die vindt die kwetsbaarheden maar wat fijn voor de "Staatsveiligheid".
Dan kunnen politie & veilgheidsdiensten namelijk makkelijker meekijken op die toestellen.


En zo worden de gebruikers overgelaten aan de fijne nukken van "de markt".

Eerst moet er een grote ramp gebeuren, voordat politici en bedrijfsleven werkelijk in beweging gaan komen om eigenaarschap van dit probleem op te eisen en het permanent te fixen.

Samsung tablets, zoals mij S8 ( de goedkoopste) krijgen om de 3 maanden een update.

Laten ze dat ook maar eens aanpakken.

Ik heb hier een Nokia T10 8inch tablet, gekocht met Android 12 een half jaar geleden voor 150 euro.
Inmiddels is dit alweer Android 13.na een update.
Kreeg van de week de laatste beveiliging updates juli van google binnen.
Denk dat mij volgende toestel een Nokia is. Dat werkt dan allemaal uitstekend daar.

Als ICT Beheerder merk ik vaak dat personeel telefoons niet updaten of dat vergeten.
Google zou eigenlijk gewoon zijn security updates moeten afdwingen tenzij opt out.
Fabrikanten hebben bij 9 van de 10 updates geen last van zo'n security update.

Ook vind ik het waardeloos dat je bij Android 2 soorten updates hebt.
1. Systeemupdate / security updates
2. Google Play Security updates
3. App Updates

Geen van alle werkt Automatisch (als zeggen ze soms van wel)

grappig, als je bedenkt dat sommige lekken van 2016 nog steeds niet gepatched zijn bij bepaalde branches.

Idd,alleen app updates,en complete systeemupdates,dat zou wel handig zijn ipv 3 soorten wat hier boven beschreven is.
Maar ja bij oude toestellen soms werken nieuwere versies van Android niet meer,mogelijk doordat de chipset dan te veel verouderd is.
Eigenlijk zou google het principe van Apple moeten hebben,dat je minstens voor vijf jaar systeemupdates zou moeten hebben.
Dat zou toch wel mogelijk moeten zijn.
Waarom lukt het met het Apple ecosysteem wel?,en met andere fabrikanten dus niet met een type chipset?.

Niet alle Samsung tablets krijgen een update en dan ook maar het eerste jaar.
Tot nog toe is Graphene OS de enige die ik snel en vaak met updates in de wwer zie. Ongeveer 30 per jaar.

Graphene is leuk maar de ondersteuning in de praktijk is best kort. Mogelijk korter dan de ondersteuning van Google zelf.

Graphene volgt AOSP. De Pixel 4 series (van 2020??) is over een paar maanden End-of-life. Dus 3 jaar aan updates. Dit is hetzelfde als iedere Samsung , Nokia enzovoort, best slecht eigenlijk - misschien dat ze het nog even verlengen zoals met de Pixel 2 maar in de Pixel 2-3 tijd kwam er niet elk jaar een nieuwe Pixel uit....

Best slecht dus , je zou verwachten dat custom roms je langer ondersteuning geven. Zo had ik met Cyanogenmod een Galaxy S2 uit het jaar huifkar die 8 jaar later gewoon een recente kernel had....

Graphene dwingt dus tot elke 3 jaar je toestel vervangen hoe frequenter Pixels gereleased worden en je weet nooit wat er op chipniveau in de silicone gestopt wordt door Google/Alphabet/NSA/Aylmao.. ze zien de userbase van Graphene ook groeien dus het zal me niet verbazen dat de Pixels vanaf 7 of 8 een paar "foutjes" in de Tensor chip hebben of in de AI chip, bijvoorbeeld in de videobewerking van de CPU , waardoor met een filmpje jouw toestel geroot word op afstand , ongeacht welke app jij gebruikt om je video te bekijken

Hier kunnen geen softwarematige jails of selinux policies tegenop namelijk......

Het probleem van Graphene is dat het een soort eenmans projectje is en je weet nooit hoe lang dat goed blijft gaan, ik zou me er niet afhankelijk van maken

Het zou die Daniel McKay sieren om zich niet zo afhankelijk te maken van de Titan M-series chip maar dit een keuze te maken, zodat mensen ook Graphene kunnen installeren op bijvoorbeeld een FairPhone...

Daarbij zijn alle Graphene toestellen dezelfde binary blobs (stuk of 5 ) en dezelfde symbols , dus zo moeilijk is het niet voor een exploit dev om de juiste return adressen te vinden voor een exploit, de enige obstacels zijn de memory management van Mckay en de sandbox maar de symboltable heb je in elk geval al.. je hoeft maar 1 ketenfout te vinden bij de compiler code optimizations in combinatie met ........ en dan ben je 1 jailbreak en 1 zeroday verwijderd van een hack

Het beste compile je Graphene project dus zelf , dan krijg je geen OTA updates want die hashes kloppen niet maar je hebt wel unieke code , het liefst sloop je de Titan afhankelijkheid eruit dan kun je Graphene op elk toestel draaien, want zeg nou eens eerlijk... de crc hash over de ROM van je toestel kun je toch ook visueel inspecteren , als je opstart zie je de string namelijk...


Eerlijk gezegd denk ik dat de toekomst niets van dit is, niets van Android maar Linux telefoons (misschien daarna BSD? want Linux kernel is default ook erg zwak qua security..het is wel stabiel maar niet secure ) gebaseerd op een XEN kernel


Je weet het gewoon niet met die custom silicons van google, wil je ze echt vertrouwen? Ik denk dat er best wel eens een hardware side channel attack in kan zitten... ik pik trouwens ook een RF signatuur op zodra ik de pixel aanzet en nog voor het laden van het OS zend de Pixel (ook vorige generaties) een specifiek signaal uit als een soort "init" op de radio chip , hij maakt welliswaar geen contact met zendmasten op een hoger OSI level maar gewoon een subtiele RF 'ping' zodra de radio module stroom krijgt

Ik vind het 1 toestel waar iedereen in de ITsec community gebruik van maakt een valkuil.......

Precies waar de NSA ons wil hebben

1 blackberry voor iedere crimineel :)

Tijd om Graphene te slopen los van de Titan chip en te porten voor generiek AOSP gebruik bijv Fairphone of voor 1 generieke chipset bijv de Qualcomm SoC
De "hardware verificatie" zou je nog altijd kunnen doen met een hardware key


Maar dan hoef je niet elke 3 jaar een nieuwe Google telefoon te kopen vanwege 1 dev zijn pipedream dat de Titan chip zijn cryptografische endlosing zou zijn, wat de pixel eigenlijk tot een linuxhackerspeeltje maakt, helaas