Google publiceert opnieuw details van Windows-lek zonder aanwezige patch

Googles Project Zero-beveiligingsteam heeft opnieuw details van een kwetsbaarheid in Windows naar buiten gebracht, zonder dat Microsoft daar een patch voor heeft ontwikkeld. Google geeft de ernst van het lek de inschatting 'gemiddeld'.

Google-onderzoeker James Forshaw schrijft in een bericht op de bugtracker dat het .Net-lek van toepassing is op versies van Windows 10 die gebruikmaken van de Device Guard-techniek voor bescherming tegen malware, bijvoorbeeld Windows 10 S. Hij meldt dat de kwetsbaarheid het uitvoeren van code mogelijk maakt, maar dat dit niet op afstand mogelijk is en dat het ook niet om een techniek gaat om hogere rechten te verkrijgen op een systeem. Een aanvaller zou al in staat moeten zijn om code op het systeem uit te voeren om het lek te misbruiken. Forshaw noemt het voorbeeld van een rce-lek in de Edge-browser.

Hij meldde het lek op 19 januari aan Microsoft, dat hem op 12 februari op de hoogte stelde dat er geen patch zou komen in de maandelijkse patchronde in april. Daarna vroeg het om uitstel en zei later dat het een patch zou uitbrengen met de release van Redstone 4. De onderzoeker zei dat er voor die release geen exacte datum bekend is en dat het probleem niet bijzonder ernstig is omdat er ook andere technieken bestaan die hetzelfde doel bereiken, die ook nog niet zouden zijn opgelost door Microsoft. Google hanteert een deadline van 90 dagen.

Deze heeft al eerder tot het publiceren van Microsoft-kwetsbaarheden geleid zonder dat er een patch aanwezig was. Bijvoorbeeld vorig jaar en eind 2016 deed zich hetzelfde verschijnsel voor, waarop Microsoft in het laatste geval met kritiek reageerde. Google zou met de beslissing te publiceren een risico voor gebruikers in het leven geroepen hebben.

Reacties (109)

[Ras]

Google geeft hiermee heel mooi zijn grenzen aan. Dit is op dit moment misschien een beveiligingsrisico voor gebruikers, maar op de lange termijn zou het beter moeten zijn voor iedereen.

Elk softwaregebruiker van software met een volgend lek kan er van profiteren. De ontwikkelaar daarvan zal namelijk met een zeer hoge mate van zekerheid weten dat ze binnen 90 dagen moeten patchen om bekendmaking voor te zijn. Als Google over zijn hart strijkt dan gaan ontwikkelaars zoals Microsoft daar vaker op gokken en worden de 0-days gevaarlijker.

[Loller1]

In welk opzicht is Microsoft's hand forceren op het testen van een patch "beter voor de gebruiker"?

[multimho]

Simpel als MS niet binnen 90 dagen serieuze lekken kan dichten, waarom vertrouwen dan toch nog steeds zoveel mensen blind erop dat zij goede spullen leveren?

Daarbij, testen van patch zou niet 3 maanden moeten duren. Kom op zeg. MS heeft heel Azure tot haar beschikking om regressie testen te draaien tegen god weet hoeveel verschillende platvormen. Google compileert en deployed Al hun software elke 15 minuten wereldwijd. Amazon zelfs nog sneller. Microsoft mag dan wel wat meer "versies" hebben maar daar kiezen ze zelf voor in hun marketing.

Nee groot gelijk dat Google de druk erop houdt. Zorgt ervoor dat Microsoft technisch een beetje bij blijft. En potdorie als we als belasting betaler 90 miljoen per jaar aan cyber security gaan uitgeven in NL dan mag je toch op zijn minst verwachten dat de belangrijkste desktop OS leverancier ook gewoon haar best doet. Anders kunnen ze wat mij betreft meteen fluiten naar een keurmerk uitgegeven door onze overheid.

[the_stickie]

Google zou ook kunnen publiceren over het lek zonder al te veel details te geven en het risico onnodig op te drijven. Iets in de trant van "we hebben een bug gevonden en dat met Microsoft besproken. Microsoft heeft beloofd te patchen maar heeft onverwacht uitstel, daarom wachten we nu even af".
Ik begrijp het principe van druk zetten door responsible disclosure en druk zetten door daarin consequent te zijn, maar het is ook wel een feit dat Microsoft security tegenwoordig serieus neemt.
Windows is een complex geheel dat zeer veel gebruikt wordt. Google zou er dus best wel wat begrip voor mogen hebben dat Microsoft niet in alle gevallen een patch supersnel buitenstampt. De potentiële impact van een slechte patch voor deze bug is waarschijnlijk veel groter dan die van een exploit. Dat is sowieso een afweging die Microsoft maakt én serieus neemt.

[gday]

Als het lek er is, kan het al misbruikt worden door anderen. Het moet dus gewoon zo snel mogelijk worden opgelost.

Daarnaast, als je nu gaat zeggen dat je gaat afwijken van de 90 dagen, is de kans aanwezig dat Microsoft de volgende keer weer roept dat ze uitstel moeten hebben. Je kunt het beste consequent zijn.

[Gomez12]

Als het lek er is, kan het al misbruikt worden door anderen. Het moet dus gewoon zo snel mogelijk worden opgelost.

Bullsh*t, anders zou je het op dag 1 publiek moeten maken en niet nog 90 dagen wachten.

Daarnaast, als je nu gaat zeggen dat je gaat afwijken van de 90 dagen, is de kans aanwezig dat Microsoft de volgende keer weer roept dat ze uitstel moeten hebben. Je kunt het beste consequent zijn.

Je kan best consequent zijn en toch meewerken. Je kan bijv voor niet ernstige problemen zeggen dat dit best 120 dagen mag zijn.

[watercoolertje]

Nee je moet een bedrijf wel de kans geven zijn fout op te lossen (dus 1 dag is juist bullshit), die krijgt de melding in volle detail al vanaf dag 1 natuurlijk. Het melden aan het grote publiek is het pressiemiddel.

[Cerberus_tm]

Maar Google hééft al uitstel gegeven, toen Microsoft daarom vroeg (zie artikel). Alleen toen Microsoft zei dat ze uitstel wilden voor onbepaalde tijd (tot een update met onbekende datum), tóén zei Google, jetzt reicht's. Google is voor zover ik het kan beoordelen echt heel redelijk en coulant geweest. Microsoft kan dit lek blijkbaar niet zoveel schelen. En ik zeg dit als Windows-gebruiker: ik geef Google hierin voorlopig gelijk.

[Verwijderd]

Juist niet. Google melde het lek aan Microsoft op 19 januari. Google heeft het lek op 19 april geopenbaard. Dat is exact 90 dagen later. Google heeft dus geen enkele uitstel gegeven.

[pepsiblik]

En ze geven dat uitstel niet omdat Microsoft uitstel voor onbepaalde tijd wilde.

[gday]

[...]

Bullsh*t, anders zou je het op dag 1 publiek moeten maken en niet nog 90 dagen wachten.

Let een beetje op je taal, wil je?

Natuurlijk kan een lek al misbruikt worden op dag 1. Zelfs vóór dag 1, want wie zegt dat Google de eerste is die het ontdekt heeft?

90 dagen is een compromis. Meer niet. Anders kun je net zo goed zeggen: openbaar het lek nooit, want dan kan het ook niet misbruikt worden.

[invic]

Idd, ik ben ook van mening dat je geen details moet zeggen en slechts in algemene bewoordingen moet publiceren. Ik geloof niet dat hackers van elk kwetsbaarheid op de hoogte is. Ze vinden natuurlijk wel fijn als het door Google of andere onderzoekers op een presenteer blaadje wordt aangedragen. Ze weten toch dat ondanks een eventuele patch veel gebruikers geen patches gaan uitvoeren. Hiermee bereiken ze het tegengestelde effect. Off topic, alsof Google zelf zo goed is met beveiliging....

[hiostu]

Laten we het dan niet gaan hebben op het security gedrocht dat Android heet... De hele wereld ligt vol met unpatched Android devices vol met bekende security issues die nooit gefixed worden of nooit gepatched worden.

[watercoolertje]

Die lekken worden ook gewoon bekend gemaakt (onder voorbehoud dat ze ontdekt zijn door project zero), wat is je punt precies?

https://bugs.chromium.org...ero/issues/detail?id=1394

Niemand weerhoudt je er van lekken in android te gaan melden overigens. Dus als je dat nodig acht, be my quest

[Primal]

Maar dat heeft weer te maken met het feit dat fabrikanten de patches die Google vrijgeeft niet doorvoeren. Hoewel je vraagtekens kunt plaatsen bij wie er verantwoordelijk is voor het creëren van het huidige ecosysteem van niet gepatchte Android apparaten, kun je dat niet bij het feit dat Google de broncode keurig voorziet van updates en veiligheidsproblemen ook oplost. In welk tijdvlak dat gebeurt is nog een andere discussie.

[Reactie gewijzigd door Primal op 24 juli 2024 18:02]

[Verwijderd]

Blijkbaar is het dus voor Google te lastig om een OS te produceren dat onafhankelijk van de fabrikanten te patchen is, zoals dat bij Windows wel mogelijk is.

[multimho]

Gaan een beetje offtopic. Android is niets meer dan een Linux kernel met een Userland. Daarna is het aan de *hardware* fabrikant om in dat Userland nog van alles te gaan lopen aanpassen. Er zijn nauwelijks telefoons met Android zoals dat beschikbaar is op de telefoons van google zelf.

Android wordt voortdurend gepatched net als de Linux kernel die erin zit. Dat die veranderingen daarna niet op de telefoons terecht komen, ligt aan de hardware fabrikanten niet aan Google.

Ingewikkeld? Valt wel mee, is wel compleet anders dan de Microsoft wereld gewend is. Windows is en blijft van Microsoft en niemand mag er een letter aan veranderen. Dus hardware leveranciers hebben Windows maar gewoon alleen te installeren meer niet. Waarom die hardware boeren dat nu opeens wel hebben met Android is een raadsel. Waarschijnlijk omdat ze denken daarmee zichzelf te kunnen onderscheiden wat ijdele hoop is imho.

[Verwijderd]

Iemand anders dan Google patched mijn telefoon? Nee, Google is daar verantwoordlijk voor. En die bouwen geen systeem waardoor er altijd gepatched kan worden zonder vendor support.

[EpicKip]

Nee niet dus, google patched je telefoon alleen als je een Nexus of Pixel hebt. De andere telefoons (min die met Treble support) hebben een koppeling aan hardware en vaak een schil/skin over android heen, updates zullen dan van de fabrikant moeten komen omdat die hun schil even aan moeten passen en moeten zorgen dat de brakke implementatie voor hardware weer werkt (hopelijk is dat op te lossen met Treble dus.).

[Verwijderd]

Dat is dus het probleem. Google kan blijkbaar geen OS maken waarbij je onafhankelijk van geinstalleerde software en skins kan patchen. Wat in Windows dus wel kan.

[EpicKip]

Dat is omdat de hardware boer wil zijn drivers niet universeel uitgeven voor iedere android versie.

En daarnaast, hetgeen wat jij beschrijft wil google doen (dat heet dus Treble) maar daar willen telefoonmakers niet aan mee werken (dan hoeft niet iedereen ieder jaar een nieuw device wat natuurlijk in de winst snijdt).

[Zarhrezz]

In welk tijdvlak dat gebeurt is nog een andere discussie.

Laten we dan gewoon uitgaan van wat Google zelf vind: 90 dagen dus.

[Rutix]

Google geeft hiermee heel mooi zijn grenzen aan. Dit is op dit moment misschien een beveiligingsrisico voor gebruikers, maar op de lange termijn zou het beter moeten zijn voor iedereen.

Elk softwaregebruiker van software met een volgend lek kan er van profiteren. De ontwikkelaar daarvan zal namelijk met een zeer hoge mate van zekerheid weten dat ze binnen 90 dagen moeten patchen om bekendmaking voor te zijn. Als Google over zijn hart strijkt dan gaan ontwikkelaars zoals Microsoft daar vaker op gokken en worden de 0-days gevaarlijker.

Het is wel meten met twee maten though. Zover ik weet hanteren ze niet echt strict die regels voor hun eigen security issues.

[Zarhrezz]

Sterker nog, ze hebben in het verleden beloofd veel ernstigere lekken in ouderen versies van Android op te lossen, om daar later op terug te komen. Dus inderdaad, Google meet op dit vlak zeker met twee maten.

Overigens gaat het hier ook om een niet heel spannende lek:

Hij meldt dat de kwetsbaarheid het uitvoeren van code mogelijk maakt, maar dat dit niet op afstand mogelijk is en dat het ook niet om een techniek gaat om hogere rechten te verkrijgen op een systeem. Een aanvaller zou al in staat moeten zijn om code op het systeem uit te voeren om het lek te misbruiken.

Dus als ik fysiek bij de PC ben en toegang heb waarbij ik mijn eigen code kan uitvoeren, kan ik dit lek misbruiken om....code uit te voeren. Die me geen hogere rechten kan geven.

Dit is volgens mij nog meer storm in een glas water dan dat Ryzen verhaal een paar weken terug.

[EnigmA-X]

Je trekt volgens mij een aantal conclusies die nergens op gebaseerd zijn.

Je hoeft bijvoorbeeld niet fysiek aanwezig te zijn om code uit te voeren. Iemand zo gek krijgen om jouw code te draaien is al voldoende. Er zijn bekende manieren (vulnerabilities) om via Edge de nodige voorbereidingen te treffen. Daarnaast de complete bedreiging wegwuiven met het feit dat je geen hogere rechten kunt krijgen lijkt mij ook niet juist.

Waar het wel om gaat is dat je door een gebruiker code te laten draaien iets in het systeem kan nestelen, persistent, waar het systeem zichzelf tegen zou moeten beschermen.

An attacker would have to already have code running on the machine to install the registry entries necessary to exploit this issue, although this could be through an RCE such as a vulnerability in Edge. There's at least two know DG bypasses in the .NET framework that are not fixed, and are still usable even on Windows 10S (e.g. https://tyranidslair.blog...-abusing-installutil.html) so this issue isn't as serious as it might have been if all known avenues for bypass were fixed.

Het is dus geen storm in een glas water. Genoeg vervelende mogelijkheden die binnen de privileges van de gebruiker uitgevoerd kunnen worden, denk bijvoorbeeld eens aan webcams of audio recording. Overigens komt bovenstaand stukje tekst gewoon uit het linkje van het nieuwsbericht.

[Zarhrezz]

Je hoeft bijvoorbeeld niet fysiek aanwezig te zijn om code uit te voeren. Iemand zo gek krijgen om jouw code te draaien is al voldoende. Er zijn bekende manieren (vulnerabilities) om via Edge de nodige voorbereidingen te treffen. Daarnaast de complete bedreiging wegwuiven met het feit dat je geen hogere rechten kunt krijgen lijkt mij ook niet juist.

Waar het wel om gaat is dat je door een gebruiker code te laten draaien iets in het systeem kan nestelen, persistent, waar het systeem zichzelf tegen zou moeten beschermen.

Dat zal alleen gaan als de gebruiker al admin rechten heeft, anders gaat dat installeren gewoon niet lukken. Als de gebruiker admin rechten heeft, kan het systeem zowieso al volledig overgenomen worden als je die gebruiker zo ver kan krijgen dat hij / zij jou code uitvoert.

Het is dus geen storm in een glas water. Genoeg vervelende mogelijkheden die binnen de privileges van de gebruiker uitgevoerd kunnen worden, denk bijvoorbeeld eens aan webcams of audio recording.

Dat is wellicht een scenario waar risico's zitten, als je met uitsluitend gebruikersrechten die recordings van de target PC (waar de aanvaller geen remote toegang tot heeft) af kan sluizen.

Maar laten we wel wezen, degene die de issue gevonden en gemeld heeft geeft al aan dat het geen heel ernstige bug is. Laten we dan van een mug geen olifant maken.

[EnigmA-X]

Het gaat om 'arbitrary code execution', je hoeft dus niets te installeren omdat je de device guard kan bypassen, het ding wat juist malware protection moet geven.

Je kunt via deze vulnerability een registrykey toevoegen en arbitrary code bootstrappen door bijvoorbeeld dotnettojscript te gebruiken. Hint: hier kan je allerlei processen mee starten. Data van een systeem afwippen is dan dus ook kinderspel.

Overigens, het is een security feature bypass en degene die de issue heeft gemeldt geeft juist wél aan dat het serieus is, omdat eerdere problemen (avenues) niet zijn opgelost!

this issue isn't as serious as it might have been if all known avenues for bypass were fixed

Qua security is dit eerder een olifant dan een mug imho.

[latka]

Ook Google krijgt 90 dagen tot disclosure. Policy is gelijk voor iedreen. En net zoals iedereen patchen ze ook niet alles.

[Rutix]

Denk je dat of weet je dat zeker? Zoals @Zarhrezz hierboven aan geeft zijn er gevallen geweest waar Google gewoon met de pet ernaar heeft gegooid.

[multimho]

Onzin. Android wordt voortdurend gepatched. Als je wil klagen over oude android telefoons moet je de naam van de leverancier noemen want google heeft daar per definitie niets mee te maken.

En wil je nu echt een open source OS qua aantal security bugs gaan vergelijken met een gedrocht als Windows? Man je kan niet beweren dat je alle gaten in Windows kent want je kunt niet bij de bron code. Dus doe het aantal fouten in de Linux kernel (en dus ook android) maar gewoon eens keer tien en dan kom je denk ik in de buurt van het aantal nog onbekende fouten in Windows op elk gegeven moment in de tijd. En dan hebben het nog niet over backlog van al reeds bekende security lekken die nog op de rol staan ergens een keer gepatched te worden door Microsoft.

[Rutix]

Windows word ook voortdurend gepatched. Ik betwijfel alleen of ze ook zo strikt zijn tegenover diensten en producten van zichzelf. Zou me niks verbazen dat er onderling word afgesproken wanneer het handig is om de 90 dagen in te laten gaan zodat het perfect voor hun uit komt.

[multimho]

Windows wordt 1x in de maand gepatched:

https://en.m.wikipedia.org/wiki/Patch_Tuesday

vergelijk met:

https://help.ubuntu.com/community/AutoWeeklyUpdateHowTo

"The default is to check daily and notify you"

[Rutix]

En wat wil je daarmee zeggen? Kernel updates worden echt niet elke dag gedaan hoor. Daar hebben ze ook gewoon een process voor en gaat ook controleerbaar. Dingen zoals dit moeten nou eenmaal zorgvuldig getest worden.

[multimho]

1. elke dag geteste kernel patches:
https://github.com/torvalds/linux/commits/master

2. Bij Linux gaan ook alle andere applicaties via een package manager, dus alles wat geïnstalleerd is wordt dan in een keer via 1 klik geüpdate als er updates voor zijn.

Dus mijn punt is dat blijkbaar de open source wereld het wel voor elkaar krijgt om voortdurend CI/CD te doen en dat dit bij Windows blijkbaar nog steeds moeilijk is.

[latka]

Ja, maar het gaat om die 90 dagen: die geld ook voor Google producten. Dat google het vervolgens niet fixed is hetzelfde probleem als wat MS heeft. 90 dagen is 90 dagen.

[Rutix]

Ja maar ik betwijfel ten zeerste of ze het ook zouden releasen na die 90 dagen als het een intern iets is. Ze zijn beide namelijk onderdeel van Google en hebben dus tegenstrijdige belangen.

[latka]

Ja, en dat is al gebeurt met Android lekken.

[Fiander]

Geen idee voor alle andere bugs en patches, maar in dit geval zou de patch met redstone 4 komen, en die is vanwege een grote bosd kans nu even uitgesteld, In dit geval had google best kunnen wachten.

weten dat een patch vanwege een groot probleem uitgesteld word, en dan toch dit doorzetten is niet erg netjes

[latka]

Er is altijd een smoes om te wachten. 90 dagen is 90 dagen. Als de code al gefixed is in Redstone 4 had je ook kunnen backporten. Maar dat kost meer tijd/geld dan roepen: wacht maar op redstone 4 en dan huilie doen als ze niet meewerken.

[2cents]

Het zou ze sieren als ze dezelfde termijn aanhouden voor hun eigen lekken. Maar dat schijnt niet altijd zo te zijn.

[gday]

Huh? Google moet zichzelf dreigen om lekken in eigen software naar buiten te brengen? Hoe zie je dat voor je?

Zulke druk moet altijd van buiten worden opgelegd, niet van binnen.

[BrutalDave]

Ik vind dit toch wel frappant. Ik snap wat anderen hier zeggen over dat anders het hek van de dam is als er geen termijnen worden gesteld. Maar de gebruikers van het OS worden op deze manier alleen maar meer kwetsbaar omdat meer van het lek afweten. Zo schiet het zijn doel ook wel voorbij.

[latka]

Het is niet bekend hoeveel mensen van het lek weten. Naast Project Zero zijn er ook blackhats en de overheid de wellicht van het lek weten. Dat vind ik veel gevaarlijker dan dat jij er van weet. Dus 90 dagen tijd en dan altijd melden lijkt de enige wijze te zijn dit soort zaken gefixed te krijgen. Van de morele ethiek van een bedrijf hoef je het iig. niet te verwachten blijkt keer op keer.

[lepel]

Google zou met de beslissing te publiceren een risico voor gebruikers in het leven geroepen hebben.

Nou... nee. Het risico bestond al, dus er bestaat een kans dat anderen het ook al hebben gevonden en het wordt misbruikt. Als Microsoft dan even op zijn gemak een fix gaat maken kunnen er mensen slachtoffer worden. 90 dagen lijkt mij prima om ontwikkelaars te geven om problemen op te lossen, ook al zijn ze zo groot als Microsoft.

[swhnld]

90 dagen om een bug te onderzoeken, een oplossing te bouwen en te testen is best kort. Ter voorbeeld, Google krijgt zijn eigen gebouwde Android nog steeds niet zo dat het gemakkelijk constant gepatcht wordt

[Bastiaan V]

90 dagen is eigenlijk belachelijk lang. Wanneer je weet dat het slot van jouw voordeur kapot is, wacht je dan ook 90 dagen voordat je er iets aan doet?

In 90 dagen hoeft er geen definitieve oplossing te zijn, maar een workaround (eventueel optioneel!) mag je van een softwarebouwer wel verwachten binnen een kwart jaar (!).
Het is prima mogelijk dat hetzelfde lek al (veel) lang(er) bekend is bij andere partijen die het actief misbruiken. Dat het moeilijker is voor MS (of Google / Apple / andere huge softwarebouwer) om een patch te testen omdat ze meer klanten hebben is natuurlijk helemaal geen reden 90+ dagen te accepteren. Het is eerder andersom, doordat er veel meer klanten zijn, zou er meer capaciteit tegenover moeten (kunnen) staan om de problemen op te lossen / te testen.

Geen enkele klant zou van een software bouwer, groot of klein, moeten accepteren dat een bekend beveiligingslek zo lang open blijft staan.

[SuperDre]

Alleen als jij weet dat jouw slot kapot is, dan ga je naar de bouwmarkt en koop je een nieuwe, das wel even wat anders dan als er een fout in het slot zelf zou zitten (en toevallig dat het enige slot beschikbaar is).
Een workaround is vaak niet eens beschikbaar. Bij een eindproduct zal het allemaal wel redelijk meevallen, maar bij een bouwsteen waar een hoop andere producten van afhankelijk zijn wordt het een ander verhaal.
En de expertise om het probleem op te lossen moet ook wel beschikbaar zijn op dat moment, niet iedereen is geschikt om alle problemen zomaar op te lossen. Ook moet je dan dus goed controleren of wat je aanpast niet weer andere problemen/lekken veroorzaakt.

[Bastiaan V]

Wanneer je een product in de markt zet (of hebt gezet) moet je ook de capaciteit beschikbaar hebben (en houden!) om deze, zolang je support belooft hebt, te onderhouden.
Dat heeft te maken met verantwoordelijkheid nemen voor je eigen producten en het serieus nemen van jouw klanten.

[SuperDre]

Grapjas, je gaat geen mensen met hun duimen laten draaien wachtend op eventuele problemen in de software, niet als het op development aan komt. Je kunt hooguit rekening houden met kleine bugfixes, maar als het probleem dieper zit moet er mogelijk de complete planning voor aangepast worden, als dat uberhaupt mogelijk is.
Wat jij aangeeft is gewoon onrealistisch.

[Bastiaan V]

Zie hier de reden waarom support of een SLA vaak totaal nutteloos is zodra de leverende partij enige grootte heeft bereikt.

[HooksForFeet]

Dat doen ze dan ook door het lek te onderzoeken, te leren waar het uit bestaat, uit te vinden hoe dat kon gebeuren, een oplossing te ontwikkelen en die grondig te testen.

Je neemt je klanten -niet- serieus door effe in een weekje een patch te maken en die online te slingeren

[swhnld]

Je bedoelt klanten zoals onze eigen overheid die het niet eens voor elkaar krijgen op tijd hun besturingssystemen te upgraden om ondersteund te blijven vanwege applicaties daarop die dan stoppen te werken?

[Bastiaan V]

Ook die vallen onder alle klanten.

Het feit dat een ander zijn zaken niet op orde heeft is geen reden om er zelf ook met de pet naar te gooien.

[swhnld]

Ik bedoelde meer aan te geven, dat als een relatief veel kleinere partij (NL Overheid) qua impact dit niet op orde kan krijgen, hoe dan met een veel grotere partij (Microsoft) die naast NL overheid alle andere overheden, applicatie ontwikkelaars, hardware vendors, en mijarden prive personen moeten ondersteunen?

Mijn ervaring met website ontwikkeling, regressie testen, PEN testen, patchen, etc. is al dat het lastig is om alles vlekkeloos werkend te houden, en dan spreek ik alleen maar over een klanten portal met een kleine 10.000 klanten.

Als Microsoft in dit geval een .NET patch er uit gooit waardoor alle websites en games die daarop gebaseerd zijn ermee stoppen, heb je de poppen aan het dansen.

[gday]

Bedoel je niet dat externe OEMs nog niet zo ver zijn dat ze de Android-patches van Google snel doorvoeren?

[Verwijderd]

Waarom ligt de verantwoordelijkheid bij de OEMs? Als ik een Windows laptop van Dell koop, dan ligt de verantwoordelijkheid toch ook niet bij Dell om mijn Windows up to date te houden? Google heeft hier gewoon technische en zakelijke keuzes gemaakt die leiden tot zeer matige veiligheid.

[swhnld]

De verantwoordelijkheid migt bij de OEM's omdat ze niet betalen voor de ondersteuning en support, maar op basis van de gratis open source variant werken. Jij kan als je handig genoeg bent morgen een eigen smaak Android bouwen en op je telefoon installeren, dat is wat al de custom rom bouwers doen. Maar Windows kun je niet zelf bouwen.

[Verwijderd]

Maar uiteindelijk komt dat toch grotendeels terug op keuzes door Google. Google heeft de licenties van Android zo in elkaar gestoken dat dit toegestaan is. En Google heeft nooit stappen genomen on dergelijk gebruik van hun OS te ontmoedigen. Dat zijn zakelijke keuzes. Op technisch vlak heeft Google er niet genoeg werk ingestoken om OEMs in staat te stellen de noodzakelijke wijzigingen aan te brengen zonder aan het OS zelf te zitten (voor Project Treble althans).

[swhnld]

Ik snap je punt, maar het is juridisch niet correct, Amazon heeft zijn eigen Android variant ontwikkeld (Fire OS) op basis van de AOSP versie en doet het wel goed. Lineage deed hetzelfde voorheen, ook geen issues mee.

In de Linuix wereld zie je niet anders met Red Hat, Ubuntu, Suse, etc. waar de open source versie niet ondersteund wordt, maar commerciele varianten erop gemaakt wel, door een leverancier die de commerciele variant maakt.

Het is een kwestie van willen, Xiaomi, Oneplus (sinds de 3), HMD, etc. doen het wel goed met updates, het kan wel.

[Verwijderd]

Als een fabrikant een volledig eigen versie van AOSP wil forken zonder enige ondersteuning van Google, het zei zo. Maar er is een groot verschil tussen een AOSP fork zoals Amazon's Fire, en een Android versie van een OHA (Open Handset Alliance) lid met door Google gelicentieerde apps. Dat heet, de Samsungs en OnePlus's van deze wereld. Zie hier voor uitleg over hoe groot Google's controle over het Android ecosysteem is: https://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/3/

Via deze al bestaande drukpunten zou Google prima de OEMs kunnen verplichten om, ik zeg maar wat, 2 jaar grote android updates te ondersteunen, en 3 jaar security updates te pushen. Of, beter nog, Google zou de OHA-afspraken, app-licenties en de technische fundamenten van Android en Play Services zo in elkaar kunnen steken dat Google zonder tussenkomst van de OEMs security patches kan pushen.

Tussen twee haakjes, ik heb een OnePlus 3 en zit nog steeds op security patch level 1 december 2017. Dus zo goed heeft OnePlus het nou ook niet voor elkaar wat betreft updates.

[pepijnm]

Maar windows heeft ook OEMs en die kunnen niet eens beslissen of hun Windows een update krijgt.

[watercoolertje]

Android word wel constant gepatched, echter niet elke telefoon.

[lepel]

Ehm, Google patcht wel maar de hardware producenten voeren niet door. Zij moeten zo noodzakelijk hun eigen smaken van Android maken, waardoor zij de patches dus weer moeten doorvoeren in hun zelf gebrouwen versie.

[latka]

Nee dat het is het niet. Alleen als je prioriteit elders ligt dan is 90 dagen te kort. Zelfde geld voor Google. Het is triviaal om alle telefoons up-to-date te houden: brick toestellen als Google Play services ziet dat ze een patch missen. Dan zijn er alleen nog maar toestellen die bij de tijd zijn. Doet Google niet: want dat doet zeer en de prio is data verzamelen, niet Android patchen.

[SuperDre]

Duidelijk iemand die nooit echt fatsoenlijke software heeft geschreven.. 90 KALENDERdagen is erg kort, voor sommige simpele BUGS niet, maar voor designflaws wel degelijk.

[multimho]

Maar goed Windows is een grote design flaw dus ja wat moeten we daarmee? Begrijpelijk dat het inderdaad lastig patchen is in die wirwar van een monoliet. Begin ergens aan te trekken valt ergens anders weer wat om. Ik geef het ze te doen. Maar dat betekent niet dat verdorie gewoon moeten zorgen dat hun rotzooi snel veiliger wordt. Hallo, heel de wereld kiest ervoor om hun desktops op dit hobby OS te laten draaien! Dat brengt wel enige verantwoordelijkheid.

[SuperDre]

Achja linux en macos zijn dan ook 1 grote designflaw, en wat moet je daar mee. Als er iets een hobbie os is, dan is dat wel linux, daar zitten ook gigantisch beel veiligheidsbugs in, maarja windows is nu eenmaal nog steeds ontzettend veel gebruikt en interessanter om over te zeiken.
De huidige windows is behoorlijk robuust.

[multimho]

Asbest is ook robuust. Duurde even voordat we hebben kunnen testen dat er nadelen aan zitten. Windows kernel source code zou gewoon vrij gegeven moeten worden zodat we de gevaren die erin zitten eruit kunnen typen. Verdient Microsoft geen euro minder om als ze dat zouden doen. Kijk naar Apple met Darwin kernel

https://en.m.wikipedia.org/wiki/Darwin_(operating_system)

Best veel geld te verdienen met die gratis software:
https://www.google.nl/amp...icrosoft-corporation.aspx

[SuperDre]

tja, alsof dat open source ook zo goed is gebleken, JAREN hebben er zware fouten gezeten in belangrijke )(security) onderdelen en dat dus terwijl de code al zo lang beschikbaar is, reviews zijn geweest en een hoop mensen de code gezien hadden. En je kunt de kernel gewoon bekijken hoor, decompileren zoals veel hackers doen is helemaal niet zo moeilijk.

[latka]

Geen idee. Vraag het mijn klanten en opdrachtgevers eens.

[Verwijderd]

Door het te publiceren is die 'kans' opeens 100% geworden.
Dus ik snap het statement wel.

Fixes voor exploit bugs moeten sowieso trouwens niet overhaast gemaakt worden. Dan krijg je patches die bochten afsnijden, niet voldoende afgedekt zijn door tests en QA overslaan. Van de regen in de drup heet dat. Dat lijkt even leuk, totdat je dat 20x gedaan hebt en je de controle over je software kwijt bent.

[Luftbanana]

Dit werpt altijd de vraag op; zijn ze nu juist wél of níet ethisch bezig met deze actie. Enerzijds wel omdat ze een kwetsbaarheid aan het licht brengen, anderzijds niet omdat ze ..tja.. een kwetsbaarheid aan het licht brengen.

[Archcry]

90 dagen lijkt mij voldoende om te reageren op een lek. Wanneer wij van een lek op de hoogte gesteld worden (zoals laatst met spectre) zorgen wij dat dit zo snel mogelijk gepatched wordt op onze producten voor klanten. Microsoft moet gewoon het probleem verhelpen en niet voor zich uitschuiven. Eigen schuld als je het mij vraagt, Google is duidelijk genoeg wat ze met lekken doen.

[Reactie gewijzigd door Archcry op 24 juli 2024 18:02]

[b2vjfvj75gjx7]

90 dagen lijkt mij voldoende om te reageren op een lek. Wanneer wij van een lek op de hoogte gesteld worden (zoals laatst met spectre) zorgen wij dat dit zo snel mogelijk gepatched wordt op onze producten voor klanten.

Maar hebben jullie ook de verantwoording over meer dan 1.500.000.000 apparaten die Windows / -software draaien?

Ik kan me voorstellen dat als jij het meest gebruikte OS voor desktop / laptop / tablet / server-clients hebt, je niet (altijd) binnen no-time iets kan patchen, enkel omdat je concurrent het openbaart in de hoop dat mensen een hekel aan je krijgen en overstappen op soortgelijke diensten van diezelfde concurrent...

[Archcry]

Nee, vandaar dat er 90 dagen gehanteerd wordt. Google zegt dat ze na 90 dagen de lekken openbaar maken. Dit is voldoende tijd om een fix uit te rollen. Vervolgens is het aan het bedrijf of zij dit ook daadwerkelijk gaan doen. In dit geval heeft Microsoft dat niet gedaan en (hopelijk) was dit een bewuste beslissing. Zoals het artikel aangeeft is het lek niet het meest gevaarlijke lek, daarom wordt het waarschijnlijk niet direct opgelost. Maar om de digitale wereld een betere plek te maken is het wel nodig om bewustwording te creëren en daarom vind ik dat Google hier niets fout doet.

Edit:
En wie houdt Microsoft tegen om hetzelfde bij Google te doen als het enkel om concurrentie gaat. Bij google zijn er ongetwijfeld ook voldoende lekken te vinden.

[Reactie gewijzigd door Archcry op 24 juli 2024 18:02]

[Loller1]

Omdat Microsoft snapt dat dat nergens op slaat en omdat een bedrijf onozel tegen je doet je niet hetzelfde terug moet doen?

Daarbij meet Google nogal met 2 maten. Waar kan ik alle beveiligingslekken mét exploit vinden die Google patched in zijn eigen software? Waar zijn al die toolkits voor Android? Als ze vinden dat iedereen het recht heeft om over een lek te weten na 90 dagen, dat ze het dan eerst eens op zichzelf toepassen.

[alexbl69]

Het is natuurlijk niet Google's taak om lekken in hun eigen software wereldkundig te maken.

Ze zullen wel een intern protocol hebben om de eigen lekken binnen 90 dagen te dichten. Of 60 dagen. Of misschien wel 120 dagen. Weten wij veel. Het staat alle concurrenten vrij om lekken in Google's software op te sporen en bekend te maken wanneer het ze goed dunkt.

Tot nu toe zijn de lekker die Google bekend heeft gemaakt voordat Microsoft een patch ervoor heeft geen showstoppers geweest. Wie weet hoeveel lekken Google aan Microsoft bekend heeft gemaakt welke wel potentiële showstoppers zijn/waren? En waarbij ze Microsoft wel meer dan 90 dagen respijt geven.

Deze politiek leert Microsoft wel om alert te zijn op meldingen van lekken. Ze zullen de meldingen van Google serieus moeten nemen, want ze weten wat de consequentie is als ze te weinig doen.

Ben er wel van overtuigd dat als ze Google ervan kunnen overtuigen dat het ze (net) niet lukt om een lek tijdig te dichten ze wel meer tijd krijgen. Als het Google immers enkel om het beschadigen van Microsoft te doen is zouden ze de lekken direct bekend maken.

[beerse]

De hoeveelheid machines waarop windows is geïnstalleerd is voor microsoft beslist niet interessant als het om patchen gaat. Dan telt alleen het aantal ondersteunde operating systemen dat het betreft. Ik tel ff snel een stuk of 10, misschien 15, waarvan een aantal de zelfde code-base hebben en het dus nog eenvoudiger maken. Uiteindelijk gaat het om de combi windows 10 en deviceguard.

Zelf kan ik mij geen instantie voorstellen die meer dan 100.000 machines beheert die geen automatisch patch systeem heeft. En gezien microsoft maandelijks patches uitbrengt hebben die allemaal 1 of andere routine om niet in 1 keer alles maar in stappen de machines van patches te voorzien.

Vooral de tussentijdse antwoorden van microsoft intrigeren mij. Eerst melden dat er geen losse patch komt en daarna dat het pas in een volgende release met nog onbekende verschijningsdatum wordt uitgebracht. Dat schept een beeld van 'het kan mij voorlopig niet schelen, het komt later wel.' Als de uitstel is omdat ze de patch niet op tijd voor elkaar krijgen, dan moeten ze dat zeggen.

[Rutix]

De hoeveelheid machines waarop windows is geïnstalleerd is voor microsoft beslist niet interessant als het om patchen gaat. Dan telt alleen het aantal ondersteunde operating systemen dat het betreft. Ik tel ff snel een stuk of 10, misschien 15, waarvan een aantal de zelfde code-base hebben en het dus nog eenvoudiger maken. Uiteindelijk gaat het om de combi windows 10 en deviceguard.

Zelf kan ik mij geen instantie voorstellen die meer dan 100.000 machines beheert die geen automatisch patch systeem heeft. En gezien microsoft maandelijks patches uitbrengt hebben die allemaal 1 of andere routine om niet in 1 keer alles maar in stappen de machines van patches te voorzien.

Alle patches moeten wel door een test straat heen die wel heel veel mogelijke situaties moet testen en ik kan je vertellen dat heel wat meer zijn dan 15 variaties.

[b2vjfvj75gjx7]

Exact, daarom noemde ik die 1.500.000.000 ook bewust.

Als je 1.000 klanten / variabelen hebt, is een testing-procedure eenvoudiger - dan wanneer je een test-street hebt die bij een enkele fout 2 miljard devices kan platleggen...

[latka]

Dat kun je wel. Je kunt de patch ook optioneel maken. Geen patch, dat is pas zwak.

[multimho]

Google heeft meer servers dan Microsoft desktops heeft. En die worden doorlopend gepatched. Het blijft mij opvallen hoe spastisch de niet open source wereld omgaat met patchen. Dat lijkt zo'n rare uitzonderlijke gebeurtenis in Microsoft wereld. Terwijl als je open source gewend bent je eigenlijk voortdurend patch. Je kunt elke dag wel via je package manager applicaties updaten. Gaat eigenlijk altijd goed. Vergelijk het maar met de ervaring die je krijgt in van die app-stores die updates pushes, zelfde concept.

Offtopic: overigens noem je in het rijtje tablets en servers maar dat klopt niet. Alleen op de krimpende desktop markt is Windows relevant en dat aantal is maar klein (naja 1,5 miljard is best groot hoor) in verhouding tot alle computers. Daarin zie dat Linux/UNIX grootste deployment heeft. Apple heeft UNIX kernel voor Mac os x en iPads en iphones, android draait Linux, meeste tv's en setop boxen ook. Over servers hoeven we het helemaal niet te hebben die draaien nagenoeg alleen maar Linux (honderden miljoenen) zij het enkele "grote" corporate environments van paar duizend Windows servers na.

[SuperDre]

Dat is wel heel erg simpel gezegd. 90 dagen is dus niet 90 werkdagen, maar kalenderdagen.
En soms is een bug simpel te fixen, maar soms is het niet zo makkelijk als het een design probleem is, je kunt niet zomaar even iets 'uitzetten' of op een andere manier fixen, er zal ook gekeken moeten worden wat de impact is op bestaande software/configuraties.
Ik weet niet wat voor producten jullie maken, maar als daar API's bij komen kijken die door 1000den andere softwareleveranciers gebruikt worden, dan zullen jullie ook niet zomaar even 'hack/slash/publish' kunnen doen, in iedergeval zeker niet met de verantwoordelijkheid die jullie hebben ten aanzien van al die andere softwareleveranciers die gebruik maken van jullie API en dan door een updateje van jullie ineens hun product niet meer werkt.

[Verwijderd]

Daarom heb je versie nummers. Maar als ik microsoft was zou ik voor kwaliteit gaan. Scannen van source code waar ongeveer hetzelfde wordt uitgevoerd gelijk meenemen. 90 dagen is veel te kort. Men denkt dat er gelijk iemand beschikbaar is. Als programmeur moet je je inlezen. Test team testen. Alle configuraties testen. Dat kost zo dagen. 180 dagen zou veel realistischer zijn.

[batjes]

Waarom geeft Google Intel 6 maanden dan? Oh ja, Intel is geen concurentie.

90 dagen kan ook veel te kort zijn, drastische wijzigingen in een OS kunnen makkelijk langer duren om te ontwikkelen en de test phase kan ook niet te min zijn.

Dit is niet de eerste keer dat Google zich aan de 90 dagen houdt richting MS, apart Google probleemloos links en rechts die richtlijn schend als het om andere partijen gaat.

MS houd na opnemen van lekken bij of deze misbruikt worden, jeuj telemetry. Ze hebben een veel duidelijker overzicht over de situatie dan een derde partij zoals Google. Erg frappant dat een derde partij mag besluiten hoe lang je er over mag doen, een partij die geen van die verantwoordelijkheden draagt als door het rushen binnen 90 dagen straks een miljard apparaten onderuit klapt. Moet je eens zien wat voor een effect dat heeft op de wereld. Gelukkig heeft MS al aangegeven dat het zich niet laat beinvloeden door deze methodes van Google en het zich niet laat rushen. Gelukkig maar, MS kan wel opboksen tegen Google, kunnen kleinere concurenten dat ook?

Het ergste is, Google, met zijn enorme security gatenkaas Android moet anderen gaan wijzen op hun gaten? meh.

[Reactie gewijzigd door batjes op 24 juli 2024 18:02]

[Armin]

90 dagen lijkt mij voldoende om te reageren op een lek

Reageren wel, maar fixen niet noodzakelijk.

Het zou dus van de reactie en soort bug moeten uitmaken hoe je je deadline stelt. Ik ben blij dat men met Meltdown geen starre 90 dagen gehandteerd heeft bijvoorbeeld.

In dit geval, denk ik echter dat bekendmaking geen probleem is gezien "De onderzoeker zei dat er voor die release geen exacte datum bekend is en dat het probleem niet bijzonder ernstig is omdat er ook andere technieken bestaan die hetzelfde doel bereiken, die ook nog niet zouden zijn opgelost door Microsoft."

[Loller1]

Als er een patch klaar staat die enkel en alleen nog getest moet worden zijn ze imo niet etisch bezig. Dat is geen process waarbij je de andere partij moet verstoren. Heck, imo als enkel blijkt dat de andere partij er niks aan wilt doen (binnen afzienbare tijd) ben je etisch bezig.

[latka]

En hoe lang mag je testen dan? Dit zijn schuivende panelen. 90 dagen is reteveel tijd om een probleem op te lossen en ook te testen. Maak er 120 dagen van en het is nog steeds te kort om te bouwen en te testen als het aan de lekkende partij ligt. Ze verdienen geen cent meer door het sneller op te lossen.

[SuperDre]

90 dagen KAN reteveel tijd zijn, maar je vergeet dat dit kalenderdagen zijn en niet werkdagen, dus weekenden en eventuele vakanties vallen al weg, dan komt er ook nog bij dat je niet elk probleem bij elke programmeur neer kan leggen, vaak komt er expertise bij om de hoek kijken, dus die personen moeten dan ook wel beschikbaar zijn.
Je bent wel heel erg naief als jij denkt dat het allemaal zo simpel is. Ja als ze mazzel hebben is het heel simpel op te lossen, maar zodra het een designflaw is, wordt het al een heel stuk moeilijker, en zeker als er miljoenen applicaties er van afhankelijk zijn, je kunt namelijk moeten zorgen dat al die applicaties na jouw patch nog steeds kunnen blijven draaien.

[latka]

Naief? Ik ben veel genoemd in mijn leven, maar nog nooit naief.
Even afpellen: kalenderdagen/werkdagen: dus als jouw klanten een probleem hebben dan werk je niet door? Dus kalenderdagen = werkdagen in mijn wereld als er shit is.
Je kunt niet ieder probleem bij iedereen neerleggen: correct, Ik denk zelfs dat het niet bij 1 persoon komt als het MS is, maar er een team naar gaat kijken. En beschikbaarheid is een kwestie van prioriteiten.
Ja het is vrij simpel, maar je kunt het moeilijk maken voor dit soort zaken te verwarren met reguliere planbare events. Ik weet het, management haat het als het niet planbaar is, maar de wereld is niet perfect. De business lekker op vakantie sturen, deadlines extenden en problemen eerst oplossen. Dat zijn prioriteiten stellen. Is dat simpel? Ja. Is het nodig: volgens mij wel als er een lek is en je weet dat het uitkomt. Als er morgen een zero-day gemeld wordt (maw. geen 90 dagen tijd) wat doe je dan? Ga je dan ook proberen het in te plannen in de release kalender om na 3 maanden met een planning te komen? Ik mag hopen van niet.

[RJG-223]

Als je als bedrijf weigert om je processen zodanig in te richten dat je binnen 90 dagen een patch kunt uitbrengen voor een probleem, dan ben je onverantwoordelijk bezig. Dan kun je de schuld wel bij een ander leggen, maar voor de buitenwacht (wij dus) is er geen verschil tussen:

'De patch staat klaar en moet enkel nog getest worden, geef ons aub 30 dagen extra'

en

'Deze bug had geen prioriteit, dus we zijn 30 dagen later begonnen met ontwikkelen, dus nu hebben we nu ook 30 dagen langer nodig om voldoende te testen'

Alleen dat laatste zeggen ze natuurlijk niet publiekelijk...

[MiesvanderLippe]

Een harde grens is de enige oplossing. Als een tijdslimiet niet gehandhaafd wordt is het hek van de dam en is dit soort onderzoek zinloos. Dat zou dan dus betekenen dat dit soort lekken langer bestaan en misbruikt worden door anderen.

[SuperDre]

Het is puur afhankelijk van wat het probleem is natuurlijk. Zo simpel als een harde grens stellen is het niet. Als jij denkt van wel, dan ben je wel heel erg naief en heb je weinig kaas gegeten van echte softwaredevelopment.

[Luftbanana]

Hm, dat zou ik zelf niet zeggen. Google snapt denk ik erg goed dat hun besturingssysteem een experiment is en dat ze Microsoft daar nooit mee in zullen halen.

Daarnaast heb je het over een security afdeling van een groot bedrijf. Uit persoonlijke ervaring zijn dit soort mensen vaak ethischer dan anderen, wat impliciet betekent dat ze niet zomaar iets doen wat tegen hun principes in gaat omdat een "big boss" zoiets zou willen.

[Ivanzoomski]

Doet Google dit nu voor een veiligere digitale wereld, of om MS in een kwaad daglicht te stellen? Of van allebei een beetje, dat kan natuurlijk ook

[wica]

Als Google het voor een veiligere digitale wereld zou doen, zou het ze sieren, als ze via hun playstore aangeven dat een bepaald model telefoon niet meer veilig is. Omdat deze niet de laatste patches meer heeft.

[Verwijderd]

MS is één van de grootste concurrenten van Google, dit doen ze dus echt niet uit de goedheid van hun hart. Anders hadden ze de lekken geheim gehouden en met MS gecommuniceerd. Edit ik lees nu dat er gecommuniceerd was.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:02]

[sugarlee89]

MS wil google's grootste concurrent zijn, maar dat zijn ze absoluut niet. En andersom ook niet.

[RJG-223]

Nog wat extra informatie voor de volledigheid: google geeft bijna routinematig extra tijd aan microsoft (en aan andere bedrijven). Bijvoorbeeld voor deze bug. Ze zijn dus beslist niet onverantwoordelijk bezig. Dat doen ze echter niet zonder toezeggingen van microsoft... ZIe hier voor een volledige lijst.

Edit: typo

[Reactie gewijzigd door RJG-223 op 24 juli 2024 18:02]

[Verwijderd]

Hard, maar eerlijk. Binnen 90 dagen moet het gepatched zijn en anders gewoon publiceren.

Anders krijg je dat fabrikanten er gewoon geen prioriteit aan geven en gewoon doorgaan met software ontwikkeling van nieuwe features.

[lasharor]

Wat is inderdaad de meerwaarde om in plaats van 60 dagen 6 dagen na het vinden van de lek deze informatie publiekelijk te maken?

[raro007]

90 dagen doet Google het.

[MiesvanderLippe]

Hij meldde het lek op 19 januari aan Microsoft, dat hem op 12 februari op de hoogte stelde dat er geen patch zou komen in de maandelijkse patchronde in april.

19 januari is gewoon 90 dagen geleden zoals Google beloofd.

[Jay47]

Eigenlijk mag Google niet zeuren, Android is ook niet 100% veillig!

[watercoolertje]

Eigenlijk mag niemand meer wat zeggen dan want niemand is perfect.

Maar nee zo werkt het niet. Dit team van Google meld ook de Android bugs (die hun ontdekken), niet enkel die van MS.

https://bugs.chromium.org...ero/issues/detail?id=1394

Dus laten we niet doen of ze hypocriet doen, of selectief zijn.