Google Project Zero laat openbaar maken bugs niet langer afhangen van fix

Project Zero, de afdeling van Google die kwetsbaarheden in software onderzoekt, zal voortaan altijd 90 dagen na een melding van een lek bij een bedrijf de details publiceren. Alleen als het getroffen bedrijf het zelf wil, komen de details eerder naar buiten.

Google gaat het nieuwe beleid een jaar lang uitproberen, meldt het bedrijf. Project Zero zal zijn bevindingen over lekken alleen eerder openbaren als het getroffen bedrijf het zelf wil, bijvoorbeeld om gebruikers niet in de war te brengen als het eerder een fix uitbrengt. In dat geval zouden gebruikers mogelijk maanden later nog eens horen over een bug die allang gerepareerd is.

Bovendien gaat het techbedrijf consequenter om met getroffen bedrijven die een incomplete fix uitbrengen. Als dat zo is, blijft de deadline voor publicatie altijd hetzelfde. Dat was in het verleden niet altijd zo. De stap moet getroffen bedrijven ertoe aanzetten sneller en beter kwetsbaarheden te repareren.

Met de wijziging hoopt Google dat het misbruiken van zero days moeilijker wordt, omdat bedrijven de lekken hopelijk sneller en beter verhelpen. De test begint per direct. Over een jaar gaat Project Zero bepalen of dit het beleid wordt voor de lange termijn. Als criminelen een lek actief misbruiken, blijft Google een deadline van een week hanteren; dat beleid is niet veranderd.

Project Zero is niet onomstreden. Het is afgelopen jaren diverse malen gebeurd dat de details over een lek naar buiten kwamen zonder dat er een fix was, waardoor aanvallers de lekken mogelijk actief konden gaan misbruiken.

Project Zero	Beleid 2019	Beleid 2020
Doelen	Snellere patches afdwingen	Snellere patches afdwingen Volledigere patches afdwingen Beter updatebeleid afdwingen
Publicatie bevindingen	Als onderzoeker dat besluit, in principe na 90 dagen	Na 90 dagen, tenzij getroffen bedrijf eerdere publicatie wil
Incomplete fix	Onderzoeker beslist of dat nieuwe kwetsbaarheid wordt met nieuwe deadline	Geen nieuwe deadline

Reacties (39)

[xrf]

Voor de duidelijkheid: het beleid van Project Zero tot nog toe was: we publiceren de details van het lek óf na 90 dagen, óf als er een fix is - welke van die twee eerder komt.

Het nieuwe beleid is nu dat Google altijd de details na 90 dagen naar buiten brengt. Als een bedrijf dus een lek eerder patcht, is de rest van de 90 dagen dus extra "wachttijd" die gebruikers van de getroffen software kunnen gebruiken om updates te installeren.

[vosManz]

Als een bedrijf dus een lek eerder patcht, is de rest van de 90 dagen dus extra "wachttijd" die gebruikers van de getroffen software kunnen gebruiken om updates te installeren.

En als een bedrijf een lek later patcht, is de tijd daartussen extra "wachttijd" die gebruikers van de getroffen software kunnen gebruiken om hun systeem te ontdoen van malware terwijl criminelen ze gewoon weer opnieuw met malware kunnen infecteren.

Natuurlijk moet een lek zo snel mogelijk opgelost worden. En natuurlijk is het goed om bedrijven te 'pushen' om het ook daadwerkelijk te fixen. Maar naar mijn mening zijn de gebruikers hier de verliezers. Die zitten immers te kijken met kwetsbare software terwijl Google mooi een lijstje met kwetsbaarheden aan kwaadwillenden aanlevert. Tevens is het naar mijn mening niet aan Google om te bepalen wat een redelijke termijn is voor het fixen van een bug. De ene bug zal snel op te lossen zijn, maar in zeer uitgebreide systemen met bijvoorbeeld veel legacy code kan een aanpassing voor het oplossen van een bug juist problemen in andere onderdelen veroorzaken. Het kan dus naast veel werk om de door Google gemelde bug te fixen/testen, ook veel werk zijn om eventuele bugs die uit het testen van de fix komen te herstellen. Maar dat maakt Google niets uit, na 90 dagen mogen criminelen het lek gewoon gebruiken in hun ransomware.

Naar mijn mening zou een 'tussenweg' beter zijn. Dus altijd informatie over het lek publiceren na 90 dagen (om het bedrijf te pushen het op te lossen) maar daar geen gedetailleerde (technische) informatie aan toevoegen tot er een fix is voor het lek (zodat kwaadwillenden er niets mee kunnen en gebruikers er geen nadeel van ondervinden).

[ocf81]

In beide gevallen is het wat mij betreft gewoon een schofterige actie dat Google niet in overleg een tijdspad overeenkomt als je de 90 dagen niet kan halen.

[rodie83]

Mwoh. De software die door Project Zero wordt onderzocht is van bedrijven die voldoende resources zouden moeten hebben om iets te fixen in 3 maanden tijd.

[batjes]

Dan verkijk je je enorm op de complexiteit van bepaalde exploits. Een maand nodig hebben om de impact van een exploit helemaal uit te vogelen en wat er allemaal veranderd moet worden is helemaal niets als de software complex genoeg is. Stukje devtijd, dan 2 maanden test straat stelt ook niets voor als je zoals Windows of de Linux kernel, miljarden systemen hebt die er afhankelijk van zijn.

Intel heeft bijna 2 jaar nodig gehad om hun CPU exploits een beetje te kunnen fixen. Die heeft destijds ook een half jaar de tijd gekregen,omdat Google Zero zich ook wel besefte dat het een heel complex beestje was. En het openbaren ging nog per ongeluk ook.

Microsoft heeft in het verleden proactief gereageerd op een report van Google Zero, meermaals contact opgenomen, want de exploit in kaart brengen, fixen en degelijk testen had gewoon meer dan 3 maanden nodig en Google dus verzocht om de exploit nog niet te openbaren. Wat doet Google, de exploit openbaren. Waardoor Google eventjes een miljard gebruikers in de stront liet zakken. Want Microsoft laat zich niet door Google intimideren en gaat geen ondegelijk geteste patches de wereld in smijten.

Google gebruikt Project Zero als marketingspraatje om concurentie mee te kakken te zetten. Dat hebben ze bij Apple ook al eens geflikt. Ze zouden ondertussen beter moeten weten dat 3 maanden geen harde deadline mag wezen.

[Jorick]

Want Microsoft laat zich niet door Google intimideren en gaat geen ondegelijk geteste patches de wereld in smijten.

Laat me niet lachen. De afgelopen jaren heeft Microsoft al meermaals aangetoond doodleuk brakke (of op zijn minst slecht tot niet geteste) Windows updates uit te rollen en dat zonder dat er maar enige druk van Google achter zat. Microsoft moet eerst maar eens bij zichzelf te rade gaan voordat ze naar anderen gaan wijzen.

[m3gA]

Sorry, maar dit is wel erg kort door de bocht. Weet je hoe ongelofelijk veel soorten hardware er ondersteund moet worden of hoe complex Windows is? We hebben het niet over een simpel software pakketje. Microsoft heeft met de verschillende rings en het openstellen van hun programma een goede zet gedaan en kan zo veel breder testen. De update frequentie is nu groter omdat Windows nu niet in 1 grote update komt maar in feature updates. Dus dan komen dit zaken vaker in het nieuws dan alleen rond het uitkomen van een nieuwe Windows versie.

[Jorick]

Microsoft heeft met de verschillende rings en het openstellen van hun programma een goede zet gedaan en kan zo veel breder testen

Dit is geen goede zet maar juist de oorzaak waarom er zoveel problemen zijn met de updates van Windows 10. Deze ex-Microsoft werknemer geeft een aardig inkijkje in waarom Windows 10 zo problematisch is met betrekking tot QA: https://www.youtube.com/watch?v=S9kn8_oztsA

De bug die er voor zorgde dat mensen data kwijt waren na een update was al veelvuldig gerapporteerd in de insider ring maar desondanks is dit niet opgepikt. Hun QA is gewoon niet up to par en dat Windows op heel veel hardware moet draaien en complex is is geen excuus om je zaken niet op orde te hebben.

Door veiligheidsissues stil te houden omdat je niet binnen 90 dagen met een fix kunt komen creëer je schijnveiligheid en daar is niemand bij gebaat. Als ze bij ProjectZero een lek kunnen vinden dan kunnen anderen met minder goede intenties dat ook. Security through obscurity is niet de manier om de veiligheid van je platform naar een hoger niveau te tillen.

[Superstoned]

Jaja. Maar voor elk bedrijf wat misschien ondanks dat ze hun stinkende best doen het niet voor elkaar bokst om in 3 maanden een patch uit te brengen zijn er echt te rot voor zijn om moeite te doen voor de veiligheid van hun gebruikers. Krokodillentranen ten spijt. Mooi voorbeeldje net van vandaag: https://twitter.com/troyhunt/status/1214829911568977921

Deze druk van Google is nog steeds hard nodig.

Trouwens, drie maanden is lang en zeuren dat Google niet lang genoeg wacht - criminelen wachten nog geen seconde en die kunnen al die tijd de bug exploiteren. Leuk dat die er in theorie niet van weten maar dat is natuurlijk nooit zeker. Beter als gebruikers zich er tenminste bewust van kunnen zijn en wellicht een apparaat van het internet kunnen halen of een ander product gebruiken.

En tenslotte. Ik ben enorm skeptisch over het idee dat er meer dan 0.0000001% security lekken is waar het onrealistisch is om binnen drie maanden een fix te maken. Aangenomen dat securitie genoeg resources krijgt natuurlijk. Ja, als je 1 ontwikkelaar op een complexe bug in een enorme code base zet kan dat een moeilijke taak zijn maar misschien zou je dan maar eens moeten gaan investeren in een team wat past bij de complexiteit (en vast ook winstmarge) van je product.

[nitien]

We kunnen allemaal hoog en laag springen. Vind het een top idee van Google en het is niet zozeer dat zij iets opdragen.

De 90 dagen termijn is een mooie eerste stap als maatstaf voor de zakelijke wereld (lees: grote/kleine bedrijven).

Nee natuurlijk kan je niet altijd zo snel een fix uitbrengen en nee het is niet slim om dan toch informatie te verzamelen en naar buiten te brengen.

Maar, we leven in digitale tijdperk. Om het beter te zeggen de digitale tijdperk begint nu pas echt. Belabberde software kan echt niet meer en lekken schieten als paddenstoelen uit de grond.

Niet te vergeten evenmin het groeiende aantal hackers en hacks. Iot devices, elektrische auto's. Wij moeten dit alleen maar willen, omarmen en supporten. Het gaat immers om onze eigen veiligheid.

Binnen vijf jaar zie ik dat overheden hier zelfs wetten op gebaseerd zullen hebben. Zie de grote hoeveelheid hacks afgelopen jaar (2019) op scholen en overige overheidsinstellingen.

[ocf81]

Er is geen beperking omtrent welke software onderzocht wordt. Als jij een open source project van een paar vrijwilligers bent dan kan dat toch knap lastig worden.

[RJG-223]

In beide gevallen is het wat mij betreft gewoon een schofterige actie dat Google niet in overleg een tijdspad overeenkomt als je de 90 dagen niet kan halen.

Over schofterig gesproken: wat pas echt schofterig is, is om als softwarebedrijf vanwege financiële redenen je gebruikers langer dan nodig kwetsbaar te laten, en ze niet alleen een fix te onthouden, maar ook het feit dat ze kwetsbaar zijn, waaraan ze misschien zelf nog iets hadden kunnen doen, als ze het maar wisten.

Er zullen best bugs zijn die echt veel tijd kosten, maar voor veruit de meeste bugs moet het mogelijk zijn in 90 dagen een (tijdelijke) fix uit te brengen. Het enige echte probleem is dat het de softwareleverancier dan meer kost...

Als jouw auto onveilig was, en de fabrikant zou vanwege financiële redenen de terugroepactie een aantal maanden uitstellen, en al die tijd liep jij en je gezin onnodig gevaar, dan zou jij ook boos zijn...

[Rutix]

Het gaat er hierom dat het gewoon een lullige actie is van Google als bedrijven proactief contact opnemen omdat de bug toch complexer is dan verwacht. Bijvoorbeeld omdat de testen lang duren of omdat uitrollen lang duurt. Als je dan gewoon alle details naar buiten gooit terwijl er aan een fix word gewerkt acteer je niet in de best interest van de gebruikers in my opinion.

[dakathefox]

Nee, dit is gewoon echt je reinste onzin... Want wat er gaat gebeuren is dat een Microsoft dan veel vaker verzoeken tot uitstel gaat indienen, alleen maar omdat het mogelijk qua planning beter uitkomt. En ondertussen is het lek open en kan er vrolijk misbruik van gemaakt worden.

[Rutix]

Als die verzoeken terecht zijn dan is daar toch niks mis mee? Je kunt ook prima vertellen dat er een kwetsbaarheid is zonder alle details vrij te geven. Als iets niet al geabused word vind ik dat je voor de gebruiker moet zorgen dat dat ook niet gaat gebeuren en dat is de verantwoordelijkheid van bouwer van de software maar ook van diegene die de lek vind.

[RJG-223]

Als die verzoeken terecht zijn [...]

En daar zit 'm nu net het probleem. Dat kan alleen de software developer beoordelen. En die oordeelt als snel in z'n eigen voordeel als dat (veel) centjes scheelt.

[Rutix]

En het antwoord op je aannames van de slechte kant van leverancier is om de gebruikers dan maar extra risico te laten lopen? Ik vind het echt grote onzin dat er niet een gulden middelweg kan worden verzonnen die voor allebei de problemen aanpakt.

[RJG-223]

En het antwoord op je aannames van de slechte kant van leverancier [...]

Het is geen slechte kant, het is een zakelijke kant. En dat is geen aanname, dat is een feit.

Het gemiddelde softwarebedrijf (dus niet per sé: '100% alle softwarebedrijven') stelt winst boven veiligheid van z'n gebruikers. Alleen wanneer (imago)schade die winst dreigt te gaan beïnvloeden wordt de veiligheid ineens wel van belang. Hoe meer tijd ze krijgen om een probleem op te lossen, hoe meer tijd ze gemiddeld zullen gebruiken, want dat scheel centjes.

[...] is om de gebruikers dan maar extra risico te laten lopen?

Een openbaar gemaakte kwetsbaarheid betekent niet dat gebruikers automatisch kwetsbaar zijn. Integendeel. Als een kwetsbaarheid openbaar is, dan kunnen de gebruikers wellicht juist tegenmaatregelen nemen, en de kwetsbaarheid juist beperken.

Daarnaast ga je we vanuit dat google op zo'n moment de enige is die kennis heeft van de kwetsbaarheid. Er zijn zat mensen, of zelfs 'bedrijven' die op ook zoek zijn naar zulke kwetsbaarheden, en die dan op de zwarte markt verkopen. Voor zulke bugs zijn gebruikers ook kwetsbaar, maar zolang google, of iemand anders die bug niet ook vindt, zal er geen patch komen, en blijven de gebruikers kwetsbaar.

Ik vind het echt grote onzin dat er niet een gulden middelweg kan worden verzonnen die voor allebei de problemen aanpakt.

Ik vind een middenweg prima, maar dan moet die niet alleen afhangen van het soort bug, maar ook van het bedrijf: als ze geen goede track-record hebben met het snel fixen van security-bugs, dan is er ook geen reden om voor de zoveelste keer extra uitstel te geven. Dan moeten ze gewoon hun organisatie op orde brengen.

En dan moet het probleem van het bedrijf niet zijn dat het alleen maar geld scheelt. Dat laaste zou een factor kunnen zijn, als het echt onevenredig veel geld is. Maar dat zal meestal niet zo zijn, zeker voor een tijdelijke fix zullen de kosten bijna nooit buitensporig zijn (vergeleken met andere security-bugs).

Bedenk ook dat de beslissing van google extreem lijkt, maar zij zijn dagelijks bezig in deze business, en zij hebben daar beslist goed over nagedacht. Zij hebben blijkbaar gemerkt dat de oude regels niet voldoende werkten. Dus proberen ze iets nieuws Als ze geen reden hadden om hun beleid aan te passen, dan zouden ze dat niet doen. Zij weten ook wel dat de beslissing controversiëel is, en een serieus bedrijf neemt zulke beslissingen niet lichtvaardig. Zeker als ze weten dat de directeur van bijv. Microsoft dan binnen een uur aan de lijn hangt om daarover te klagen...

Daarnaast zou een overweging van google kunnen zijn, dat bedrijven die geen uitstel krijgen, terwijl anderen dat wel krijgen, zich oneerlijk behandeld zullen voelen. Zeker als weer eens in het nieuws is dat een groot bedrijf als Microsoft een half jaar extra de tijd heeft gekregen van google. Misschien dat zo'n bedrijf zelfs wel een rechtszaak aan zou kunnen spannen. Als er eenduidige, objectieve regels zijn, dan is de kans op dat alles kleiner.

[RJG-223]

Het is natuurlijk lastig hierin een goede balans te vinden die de belangen van alle partijen voldoende beschermt. Als een bedrijf proactief zegt meer dan 90 dagen nodig te hebben, kan dat ook gewoon betekenen dat ze het probleem onvoldoende prioriteit hebben gegeven. Een goede balans zou kunnen afhangen van het soort bug, en van de vraag of het bedrijf normaal redelijk snel is met fixes. Voor een bedrijf dat altijd meer dan 90 dagen nodig heeft, is een harde grens misschien de enige manier om te zorgen dat ze voldoende oog krijgen voor de belangen van hun klanten. Helaas: hoe dan ook, wat je ook doet, er zullen altijd mensen/bedrijven zijn voor wie het onterecht nadelig uitpakt.

Trouwens: gebruikers hebben er vaak ook belang bij om te weten dát ze kwetsbaar zijn, zelfs al is er nog geen patch.

Overigens reageerde ik vooral op het ongenuanceerde gebruik van het woord 'schofterig', en wilde ik primair daarop wat tegengas geven.

[ocf81]

Met de stap om eventueel in overleg toch langer dan 90 dagen te wachten te laten vallen is er wat mij betreft niks ongenuanceerds aan het woord schofterig als het om het gedrag van google gaat.

[RJG-223]

Met de stap om eventueel in overleg toch langer dan 90 dagen te wachten te laten vallen is er wat mij betreft niks ongenuanceerds aan het woord schofterig als het om het gedrag van google gaat.

Even schofterig dus als een software developer die, omdat het iets meer kost, vele maanden wacht met een fix, tot bijvoorbeeld de volgende release, of die überhaupt geen fix uitbrengt, en ondertussen z'n klanten kwetsbaar laat zijn zonder dat die klanten de mogelijke schade kunnen beperken, want ze weten het niet eens.

[ocf81]

Als jij in jouw werk een foutje maakt, wil jij dan ook zonder betalingsregeling de boete betalen als die hoger is dan je salaris?

Google gaat nu een stap verder. Zelfs als het niet te doen is om binnen de 90 dagen een fix te deployen gaan ze over tot publicatie. Google gaat nu een grens voorbij. Dit is gewoon een vorm van afpersing geworden. Ze moeten hiervoor ter verantwoording worden geroepen.

[tweaknico]

Mogelijk is je product te complex en niet voldoende gepartitioneerd.

Als het goed is krijg je als ontwikkelaar MEER dan alleen de mededeling dat er iets niet in de haak is, de analyze als black box test zit er bij (als het goed is).
Daarnaast heb je als ontwikkelaar mogelijk nagelaten om tijdens het ontwikkelen van je product voldoende testen uit te voeren VOOR publicatie & distributie van je product om het geheel uberhaupt te voorkomen.
(als vergelijking met boete: voorkomen dat je een boete oploopt?).

[Reactie gewijzigd door tweaknico op 22 juli 2024 16:09]

[svenk91]

Wat is er mis met financiële redenen? Je hebt liever dat ze failliet gaan aan 1 fix en daarna nooit meer iets kunnen fixen? Een bedrijf moet ook duurzaam opereren om continue support te kunnen leveren, ze kunnen niet alles op alles zetten voor een bug fix.

Financiële overwegingen hebben echt veel meer impact dan wat extra centen in de zak van de aandeelhouders (het merendeel van de software komt geeneens van beurs genoteerde bedrijven, vaak zelfs van vrijwilligers).

De rest van je verhaal ben ik het wel mee eens, ik wil vooral een punt maken dat financiële redenen zeker niet op zichzelf erg zijn als redenen om een fix later (of zelfs niet, mits je duidelijk en tijdig het einde van support vermeldt) uit te brengen.

[latka]

Het is pas schofterig om je klanten met software met lekken te laten werken tenzij je denkt dat criminelen de google zero resultaten als enigste bron van informatie gebruiken.

[latka]

Ik zie het toch anders: als je in 90 dagen geen exploit kan dichten moet je je afvragen of je nog in deze IT wereld thuishoort. In 1980 kon je er nog mee wegkomen, maar sinds de Morris Worm uit 1988 mag duidelijk zijn dat exploits eenvoudig en snel via een netwerk hun weg vinden. 90 dagen is in internet tijd een eeuwigheid. Dat iets moeilijk is mag geen excuus zijn. Je had je er al 30 jaar op kunnen voorbereiden.

[ocf81]

Doen alsof afpersing acceptabel is is gewoon immoreel wat mij betreft. Hoe snel criminelen een lek vinden en gebruiken ligt ook aan hoe makkelijk een lek op te sporen is. Met een noticeboard voor lekken is dat toch een stuk makkelijker.

[latka]

Afpersing?? Wil Google geld zien om het tegen te houden. En criminelen zullen niet zelf zoeken maar er is ook een markt voor hacks waar je gericht in kunt kopen. En natuurlijk de allom gevreesde russische staatshackers. IT is verworden tot een integraal onderdeel van het leven en derhalve gewoon een (militair) doelwit geworden. Vandaar dat ik altijd wat allergisch reageer op mensen die roepen dat het niet eerlijk is en moeilijk om zo snel bugs te fixen. Als de Boeing vliegtuigen naar beneden vallen worden ze ook gewoon aan de grond gezet. Ik denk dat voor IT systemen er ook gewoon een dergelijk beleid moet zijn (ofwel: strafbaar zijn als je onveilige apparatuur aan het internet koppelt).

[ocf81]

Ze willen een tegenprestatie. Ze dreigen dus met een schadelijk verhaal en dan een tegenprestatie eisen. Dat is toch wel klassieke afpersing.

[latka]

Nee, ze dreigen niet. Ze maken het openbaar. Na 90 dagen. Of jij je huiswerk doet of niet. Dat is geen dreigen. Dat zou zijn als je zegt: 1 miljoen of me maken het openbaar. Ik zie dit meer als je verantwoordelijkheid nemen als vinder van de bug en hopelijk ook als maken van de software door een oplossing te bieden.

[Verwijderd]

Ach zolang er nog hacks worden gepleegd met bugs van 5 tot 10 jaar oud is dit niet zo’n punt natuurlijk.

[vosManz]

Juist wel, die hacks worden gepleegd met bugs die al jaren in een systeem zitten, maar meestal pas recent bekend zijn geworden. Zolang een bug/lek niet bekend is en er dus geen misbruik van wordt gemaakt is het niet direct een probleem/risico, dat wordt het pas als de verkeerde mensen weten dat het lek bestaat en er misbruik van kunnen maken. Als Google die op een presenteerblaadje gaat aanleveren wordt dat voor criminelen natuurlijk alleen maar gemakkelijker.

En natuurlijk worden er ook bugs door gefixt, wat natuurlijk goed is. Maar dat bekendmaken na 90 dagen ook als er geen fix is mag Google wat mij betreft achterwege laten.

[Verwijderd]

Sorry maar dat bedoel ik toch echt niet. Genoeg bedrijven die jaren achter lopen met patchen. Anders consumenten wel. Zero days? Negen van de tien keer is een 180 day of een 500 day ook prima.

[vosManz]

Ah, dan had ik je verkeerd begrepen. Dat bedrijven zo ver achterlopen is inderdaad een kwalijke zaak. Voor consumenten geldt dat natuurlijk ook, maar met de auto-update mechanismes van tegenwoordig en als er wel gewoon al lang een patch beschikbaar is ook wel een beetje eigen schuld als je dan slachtoffer wordt van malware. (al is het natuurlijk ook nadelig voor andere gebruikers als je apparatuur onderdeel wordt van een botnet of iets dergelijks).

[MrMonkE]

Juist wel, die hacks worden gepleegd met bugs die al jaren in een systeem zitten, maar meestal pas recent bekend zijn geworden.

Misschien kent de Mossad, KGB, CIA of welke andere malafide partij de bug al jaren.
Zij zullen hem zeker niet aanbieden als ze hem vinden.

[well0549]

Goede zaak.
Internet moet veiliger.
Vrees dat dit de enige manier is.

Maar MS, Amazon en Apple zouden ook wel een project zero mogen beginnen...

[beerse]

Mijn grote vraag is hoe ze hier zelf mee om gaan. Issues met systemen die door google geleverd worden: Wie bepaald wanneer het gevonden is? Wie bepaald wanneer die 90 dagen zijn verlopen? Zijn dat kalender dagen? Zijn dat werk dagen? Hopelijk heeft project Zero een redelijke 'status apparte' binnen Google om haar punt hard te maken.

En dan is er voor google software nog de gelaagde levering aan de gebruikers: een android update kan dan wel binnen 90 dagen bij google vandaan komen, maar hoe lang duurt het voordat het door druppelt naar de eindgebruiker? Als het er al komt?

[latka]

Die hebben ze en ook Google producten worden onder de loep genomen. En het doordruppelen is beter geworden maar eigenlijk is het alleen zo dat Android One/Google eigen producten deze updates vrij rap hebben. Maar het is dan ook mijn overtuiging dat je nooit en te nimmer een of andere Android telefoon moet kopen met een mooie custom skin omdat je weet dat dat op termijn altijd betekent dat updates niet of nauwelijks op tijd doorkomen,