Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google: bescherming tegen Spectre-aanvallen voor Chrome-desktopversies is actief

Google heeft een beveiligingsmaatregel ingeschakeld voor het overgrote deel van de desktopgebruikers van zijn Chrome-browser. Het gaat om de feature site isolation, die moet voorkomen dat kwaadaardige websites gevoelige informatie stelen.

Google meldt dat de functie inmiddels voor 99 procent van de Chrome-gebruikers standaard is ingeschakeld, waarbij de laatste 1 procent wordt gebruikt om prestaties in de gaten te houden en zo nodig te verbeteren. De introductie van de functie vond plaats in versie 67 van Chrome, die eind mei uitkwam. In versie 66 van de browser voerde Google een beperkte test van de functie uit onder gebruikers, maakte het bekend bij de release van die versie. Het was voor zakelijke gebruikers al langer mogelijk om site isolation in te schakelen via een flag. Die mogelijkheid bestond sinds Chrome 63.

Illustratie van Google

De functie moet voorkomen dat een kwaadaardige website in staat is om gevoelige informatie te stelen van een andere website die geopend is in de browser, aldus Google. Het is een soort 'tweedelijnsverdediging', omdat same origin policy in principe al voorkomt dat websites gegevens van elkaar kunnen inzien. Site isolation gaat verder dan dat, doordat pagina's van verschillende websites in aparte processen en eigen sandboxes worden ondergebracht. Dat geldt onder meer voor tabs en iframes. Volgens Google heeft de maatregel tot gevolg dat Chrome ongeveer tien tot dertien procent meer geheugen gebruikt.

Het bedrijf schrijft dat het door het isoleren van renderer processes per site afhankelijk is van het besturingssysteem om daadwerkelijk aanvallen tussen processen te voorkomen. Voordat de functie in Chrome aanwezig was, werd een iframe van een andere site in hetzelfde proces ondergebracht als dat van de site waarop de gebruiker op dat moment aanwezig was. Dat kon ertoe leiden dat een aanvaller een succesvolle Spectre-aanval kon uitvoeren. Een dergelijke aanval maakt het uitlezen van gevoelige gegevens mogelijk, in de browser bijvoorbeeld cookies of wachtwoorden.

Google zegt dat het nu gaat onderzoeken op welke manier site isolation te integreren is in de mobiele Android-Chrome-browser. Of dat ook in de iOS-versie gebeurt, vermeldt de zoekgigant niet. Google start een experimentele implementatie voor zakelijke gebruikers in versie 68 van de Android-versie. Het bedrijf had al tegenmaatregelen in Chrome geïntroduceerd bij de publicatie van Meltdown en Spectre in januari, bijvoorbeeld door timers minder precies te maken. Deze maatregelen draait het nu weer terug, omdat die dankzij site isolation niet meer nodig zijn.

Door Sander van Voorst

Nieuwsredacteur

12-07-2018 • 10:34

63 Linkedin Google+

Reacties (63)

Wijzig sortering
Wat ARM betreft ben ik ook niet volledig op de hoogte, ik begreep echter wel juist het tegenover gestelde, dat ARM meer de Intel kant op zit (want bijv. ook vatbaar voor Meltdown).
Nee, er zijn maar een zeer beperkt aantal ARM SoCs vulnerable voor Meltdown.
De inhaalslag van XP waar ik het over had, begon tijdens XP's levensduur en heeft tot Windows 7 ergens geduurd. Toen het internet zich naar de massa aan het verplaatsen was (alleen makkelijker om Windows periodes te gebruiken)

De huidige inhaalslag is een jaar, misschien 2 geleden gestart?

Ging me niet om Windows 2000, maar om het jaar 2000 :P Tot aan het jaar ~2000 na Christus, werd security in de IT totaal niet serieus genomen.

Er zijn wel verbeteringen op veiligheidsgebied geweest. Linux liep daar een aantal jaar mee voorop op Windows. Maar... het was zoals je zelf ook al aangeeft. Niet serieus genomen.
En ook dat klopt niet. Vooral bij de Unixes is security altijd belangrijk geweest, zowel in de vorm van hardware (process and privilige separation, execute permission) als software (chroot jails, buffer overflow hardening). Zoals ik eerder al zei zijn side channel attacks relatief nieuw, voor AES had ik er nog nooit van gehoord.
Helaas schijnt ECC ook niet echt te beschermen tegen rowhammer. Normaal DDR4 van Samsung of SK Hynix waarschijnlijk dan weer wel (niet van Crucial, en ook niet low-power-geheugen). Dat is in elk geval het laatste dat ik erover gelezen heb.
Daarom moet je ECC ook combineren met memory address scrambling. Of je gebruikt Chipkill, die kan ook burst errors corrigeren.
...en dan van de genoemde fabrikanten!
Is de gedachte misschien in je opgekomen dat het misschien ook te maken heeft met, upgraden voor velen zinloos is sinds medio 2014?

Zo heeft de consument natuurlijk weer een goede reden om in de (nabije) toekomst te upgraden.
Heb je gelijk in, echter doe ik op dat moment een reinstall van windows en is het probleem weg. Een geplunderde rekening lijkt mij vrij stug. Als je al drops hebt naar 40fps, dan zijn de paar extra FPS toch echt een hoop waard ;)
Een geplunderde rekening lijkt mij vrij stug.
Niks stugs aan maar realiteit en heel goed mogelijk
Heb je meer dan 100 tabs open soms?!
Niet meer dan 100, maar over de 50 zit ik over het algemeen nogal vlug.
Helaas 🥜 kaas, veiligheid gaat boven performance. Tijd voor een andere browser of workstation. Visual Studio nou ook weer niet zo demanding en Chrome gebruikt nu eenmaal veel ram.
Heb je toevallig ook bronnen voor dit performance verlies, en dan het liefst geen synthetische benchmarks. Het zijn namelijk cijfers die je veel hoort, maar veelal onderbouwd met synthetische benchmarks en / of totaal onrealistische (test) workloads, die in ieder geval in mijn ervaring totaal niet representatief zijn voor het daadwerkelijke verlies in bijvoorbeeld een gemiddelde bedrijfsomgeving, on-premise of bijvoorbeeld in een datacenter. Maar ook niet representatief zijn voor bijvoorbeeld gaming pc's of het performance verlies dat tante ingrid heeft bij het browsen of het typen van een briefje.

Ik heb hier vooral zakelijk, maar ook privé testen voor uitgevoerd. En ik kom eigenlijk bij realistische workloads voornamelijk op verliezen van 0 tot 5%, zowel bij kantoorwerk scenario's (beetje browsen, office applicaties, erp e.d.), gaming tests (voornamelijk prive) maar ook bij volledig operationele vSphere of Hyper-V clusters zie ik gemiddeld in de praktijk zo'n 0-5% verlies, en dan vaker dichter bij de 0% dan bij de 5%. Enkel bij bepaalde niche scenario's (hoog aantal i/o's) is het verlies wat hoger (tot 15% voor die speciifieke workload).

[Reactie gewijzigd door Dennism op 12 juli 2018 11:53]

Heb je toevallig ook bronnen voor dit performance verlies, en dan het liefst geen synthetische benchmarks. Het zijn namelijk cijfers die je veel hoort, maar veelal onderbouwd met synthetische benchmarks en / of totaal onrealistische (test) workloads.
Bron: LKML (linux kernel mailinglist), logisch nadenken met gezond verstand.

Het vervelende is dat er eigenlijk geen getal op te plakken is, want het is compleet afhankelijk van de workload die een machine heeft. Het probleem is dat de pipelines en het cache van de processor leeg moeten bij iedere switch naar een ander proces om te voorkomen dat er op deze plaatsen data van het ene naar het andere proces kan weglekken. Dit kost gewoon erg veel tijd.

Al men PCID heeft, dan biedt de hardware de garantie dat het ene proces niet bij de data in de pipelines of het cache van een ander proces kan. Deze checks kosten minder tijd dan het flushen van de pipelines en het cache, maar ze kosten eveneens nog steeds tijd en alles dat tijd kost, heeft impact op de performance.

Het is zeer moeilijk om te zeggen hoeveel tijd het precies gaat kosten, omdat impact op de performance wordt bepaald door het aantal context-switches dat uw software van uw systeem vereist.

Draait u een game en zit alles in ram, dan zal het allemaal wel meevallen, maar draait u een database of webserver die bij elke request een operatie op de harddisk moet doen, dan gaat de performance misschien nog wel verder naar beneden dan die 35% procent. Elke operatie op de harddisk vereist namelijk een context-switch, zodat de kernel zijn ding kan doen.
Ik heb hier vooral zakelijk, maar ook privé testen voor uitgevoerd. En ik kom eigenlijk bij realistische workloads voornamelijk op verliezen van 0 tot 5%, zowel bij kantoorwerk scenario's (beetje browsen, office applicaties, erp e.d.), gaming tests (voornamelijk prive) maar ook bij volledig operationele vSphere of Hyper-V clusters zie ik gemiddeld in de praktijk zo'n 0-5% verlies, en dan vaker dichter bij de 0% dan bij de 5%. Enkel bij bepaalde niche scenario's (hoog aantal i/o's) is het verlies wat hoger (tot 15% voor die speciifieke workload).
Zo te zien heeft u dus een workload waarin u "mazzel" heeft en de schade meevalt. Blij mee wezen. Ik heb zelf een synthetische benchmark gedraait en in een absurd scenario zelfs een verlies van 43% gezien. Inderdaad bij een hoog aantal IO's. Bij een andere synthetische benchmark met een krankzinnig hoog aantal threads kwam ik uit op 19% verlies. Met PCID aan bleef de schade op beide gevallen steken op 4% tot 6%.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 12:13]

LMKL heb ik hetzelfde probleem mee, alle (of in ieder geval de meeste) daar genoemde cijfers zijn synthetics. Ik, in prive, of onze klanten (zakelijk) wil niet weten wat ik in een theoretische situatie zou kunnen verliezen in een worst case scenario, maar wat we verliezen bij ons normale gebruik (het ene gebruik is natuurlijk het andere niet.

Synthetics geven in principe alleen een antwoord op de mogelijke maximale performance in een bepaalde situatie. Iemand ziet 30% staan en gaat roepen "Intel verliest 30% performance!!!1111!!11", terwijl het goed mogelijk is dat er op zijn workload 0% verlies is. Ik heb echt het gevoel dat er zoveel misinformatie het net op wordt geslingerd over bijv. Spectre en Meltdown performance verlies, die in 9 van de 10 realworld situaties niet eens in de buurt komt van het vaak rond geschreeuwde "Tot wel 35% verlies" verlies.
Zo te zien heeft u dus een workload waarin u "mazzel" heeft en de schade meevalt. Blij mee wezen. Ik heb zelf een synthetische benchmark gedraait en in een absurd scenario zelfs een verlies van 43% gezien. Inderdaad bij een hoog aantal IO's. Bij een andere synthetische benchmark met een krankzinnig hoog aantal threads kwam ik uit op 19% verlies. Met PCID aan bleef de schade op beide gevallen steken op 4% tot 6%.
Dat ik, of onze zakelijke relaties "mazzel" zouden hebben geloof ik niet zo. Dit zijn waardes (grotendeels amper verlies per workload (de genoemde 0-5% en dan vaker 0 dan 5%, soms een uitschieter met wat meer verlies, de genoemde 10-15%) die ik consistent zie over een redelijk aantal zakelijke MKB omgevingen (50 tot 1000 seats) met applicatie servers, RDS servers, webservers, RDS servers, database servers. Als het alleen mijn prive PC zou zijn zou ik inderdaad nog over "mazzel" kunnen spreken, heb je helemaal gelijk in. Maar consistente cijfers over een paar duizend werkplekken en bijbehorende workloads dan doet dat mij toch echt denken dat de theoretische (synthetische) verliezen de connectie met de cijfers in de praktijk totaal verloren hebben en zeer overdreven worden in de berichtgeving.

Zeg bijvoorbeeld zelf, jij ziet 43% en 19% verlies in synthetics, maar hoeveel meetbaar / merkbaar verlies heb jij zelf op bijvoorbeeld een dag werken in real world workloads.

[Reactie gewijzigd door Dennism op 12 juli 2018 12:42]

U heeft zo te zien vooral de typische office-MKB workloads. Daar gaat u weinig verschil merken, want de invloed van spectre en meltdown zijn voor deze workloads weinig interessant. Ik kan echter niet uitsluiten dat het in de toekomst nog relevant wordt.

Zoals het er nu uitziet, zijn de de database- en storage-servers de enige plaatsen waar u in dergelijke omgevingen noemenswaardige problemen zou kunnen ondervinden.
Voor zover ik weet, is bij het gemiddelde MKB de impact weinig relevant omdat andere factoren zoals de netwerkverbinding of de beeldcompressie van een RDS (ik neem aan dat u Remote Desktop Servers bedoelt) vaak domineren. Beiden vereisen relatief weinig context-switches en meestal heeft het MKB toch meer rekenkracht in huis dan dat zij strikt nodig heeft.

Echter zit ik zelf niet in de MKB-wereld, dus dergelijke informatie heb ik niet voor handen. Zelf werk ik vooral aan de backends van grote webservices die tijdens kantooruren honderden requests per seconde krijgen en daar is de impact wel merkbaar, maar (nu nog) meestal rond de 10%.

Houdt er echter wel rekening mee dat het deksel net pas van de beerput af is en nog lang niet alle vormen van deze processorbugs zijn gevonden. Laat staan opgelost en gepatcht. Er zijn al een paar nieuwe varianten ontdekt waar de huidige patches niet tegen werken en er komen in de toekomst, met een aan zekerheid grenzende waarschijnlijkheid, nog wel meer lijken uit de kast vallen met betrekking tot "speculative execution".

Ik heb geen idee wat er daardoor nog performance penalty's bij kan komen, omdat alle software-mitigations anders dan, "flush cache, flush pipelines" geen definitieve oplossingen zijn en in het (theoretisch) ergste geval gaat uw performance zelfs naar 1/20-ste van uw huidige performance. Nou zal de soep niet zo heet worden gegeten als dat deze wordt opgediend, daarin geef ik u zeker gelijk, maar u leest wel correct dat elke CPU van vanaf ongeveer 1998 zonder speculative execution (en dus vrij van deze problemen) het in bepaalde gevallen beter kan doen, dan een moderne cpu met spectre-patches. Speculative execution is namelijk één van de fundamentele technieken die voor de speedups van de laatste 20 jaar heeft gezorgd. En daar is, door ontwerpfouten in veel processoren, nu dus iets mis mee.

Wat ik wel zeker weet is dat deze ellende bij ons zal blijven, totdat Intel en AMD hun processor-designs hebben aangepast en iedereen zijn oude processoren heeft vervangen.
Dit gaat dus zo nog 10 tot 15 jaar duren en gedurende die tijd zullen wij nog een aantal keren nieuwe varianten zien opduiken, waar de huidige software niet tegen bestand is.

Ik hoop dat u nu begrijpt waarom de berichtgeving klinkt alsof het van een aantal onheilsprofeten af komt, want "wij" als mensheid zitten inzake speculative execution wel degelijk met een heel groot probleem. Aan de andere kant hoop ik ook dat u nu begrijpt, dat de auteurs van deze patches niets anders kunnen doen dan het maken van een synthetische benchmark, om vervolgens te concluderen "dat het allemaal wel meevalt" en dat de meeste mensen in de praktijk geen tot weinig problemen zullen ondervinden. Maar u zal maar een grote bank, overheid, Equens (alle pin-betalingen), Apple, Microsoft of Google zijn en dan ineens ontdekken dat u door een paar stomme fouten van Intel en AMD, nu 1/3e van uw serverpark mag bijzetten door een paar patches....

Het zijn de systemen waarop men werkt met gevoelige data, of grote bergen data en code van veel verschillende auteurs, die echt geraakt worden. Dus: alle cloud-providers, banken, medische dienstverleners, payment processors, en zo voort. Dat zijn minstens evenveel computers als er bij de mensen thuis staan.

[Reactie gewijzigd door vliegendekat op 12 juli 2018 13:59]

Ik ben het zeker met je eens dat de impact voor reuzen als Google, Amazon, Microsoft een stuk groter is dan voor de gemiddelde consument, of zelfs zakelijke gebruiker.

En dat we met een groot probleem zitten is natuurlijk hopelijk voor iedereen duidelijk, totdat er nieuwe generaties cpu's komen zal het pappen en nathouden zijn met microcode, OS patches en software patches, heb je 100% gelijk in. En dan nog de vraag of dit wel 100% opgelost kan worden zonder ons terug te brengen naar de digitale spreekwoordelijk "steentijd", ook daar heb je zeker gelijk in. Dat er mogelijk nog een berg nieuwe lijken uit de kast gaan vallen heb ik hier ook al vaker voor gewaarschuwd :)

Mijn punt is echter een beetje, wat nu naar mijn mening veelal juist gemist wordt. In plaats van consumenten correct te berichten en aan de te geven dat dit ernstige lekken zijn, beveiliging benodigd is, en dat voor de consument de performance impact nihil is (in ieder geval op dit moment). Zie je dat hier, maar ook op andere sites er juist iedere keer weer een berg "doomsayers" op staan in de reacties en soms zelfs in de nieuw berichten zelf die beginnen over "Tot 35% performance verlies!!111!!!11!" "Installeer geen patches want je PC wordt 30% langzamer!!!!" zonder enige begeleidende context dat deze verliezen alleen gezien worden in zeer specifieke workloads, waardoor iedereen die dat leest en wat minder ingewijd is gelijk denk dat als hij de patches installeert zijn favoriete games ineens 25 of 30% langzamer kunnen lopen of dat zijn PC niets meer waard is. Hierdoor weet de consument, maar ook zakelijke gebruikers, eigenlijk niet meer wat nu daadwerkelijk echt te impact is voor hem. En dat wordt mijn inziens regelmatig slecht gecommuniceerd.

Ik bedoel bericht rustig over de performance impact, maar lever er ook de juiste context (Impact X bij workload Y) bij en geen blanket statements van "Tot 35%!". Ingrid die aan het browsen is zal namelijk echt geen 35% performance verlies hebben, Microsoft of Amazon die voor Pietje Puk B.V. een i/o heavy database workload in Azure of AWS draait zal mogelijk echter wel een flinke impact hebben

[Reactie gewijzigd door Dennism op 12 juli 2018 14:29]

AWS, had er juist door de manier waarop men het heeft opgezet, geen last van spectre en dergelijke. Ze hadden wel last van Rowhammer, maar dat is een totaal ander verhaal.

Ik snap uw punt over het correct informeren van consumenten en zakelijke partners...

Ik pak het meestal als volgt aan:
Wat spectre en meltdown zijn leg ik aan leken meestal uit aan de hand van een spoorwegennetwerk rondom een militaire basis of fabriek en stel dan dat je een hoop af kan leiden door te observeren wat er in en uit gaat. Daarna stel ik dat de boel inderdaad trager kan worden door te eisen dat een station volledig moet worden vrij gemaakt van passagiers, koffers, tassen, zwerfvuil en dat alle afvalbakken geleegd moeten worden, voordat de volgende trein er mag stoppen of er zelfs maar doorheen mag rijden. Hoe erg de boel vertraagt, is grotendeels afhankelijk van de frequentie waarmee u dit doet. Één keer per dag? Geen probleem! Ieder uur of vaker? Groot probleem! Maar in plaats van één keer per dag praten we in een computer dan wel over minimaal 10-duizend keer per seconde of vaker, terwijl we maar pakweg 2 miljard dingen per seconde kunnen doen en pakweg een paar miljoen keer een andere trein door het station kunnen sturen.

Ik zeg er ook altijd bij, dat als u dit soort informatie van mij moet vernemen, dat u dan gewoon de patches moet installeren en braaf moet doen wat de Microsoft- of Apple-goden u min of meer opdragen. Als de boel daarna alsnog te traag wordt, kunt u het beter tolereren en een paar honderdjes of duizendjes aftikken voor nieuwe apparatuur waarmee u de lasten verlicht of waarin dit alles gerepareerd is. De schade die u zich mogelijk op de hals haalt door de patches en updates niet te installeren is waarschijnlijk vele malen groter dan die paar honderdjes of duizendjes.

Verder onderstreep ik vaak ook heel erg het feit dat het gebruik van anti-virussoftware en adblockers, het halen van updates, het uitschakelen van javascript (en als dit niet kan, dan moet men erop aandringen bij de leveranciers), het niet insteken van onbekende usb-sticks of BYOD-apparaten, het niet lukraak openen van alle bijlagen en het niet installeren van allerlei software software en frameworks zonder uitgebreide inspectie (en ja dat geldt ook voor de developers met al hun "kleine" rot-tooltjes en tienduizenden bibliotheken die men aan elkaar lijmt), door deze lekken nu nog belangrijker is geworden dan ooit tevoren. Immers: Als u hier geen gade op slaat, is het alsof u alles en iedereen toestaat om mee te kijken (en schrijven) terwijl u uw pincode of wachtwoord intoetst en daarna uw bankpas in het apparaat laat zitten. Dit is immers precies wat de meltdown en spectre bugs in de chips mogelijk maken.
Google neemt dus gewoon het zekere voor het onzekere en voegt maar gewoon een extra laag beveiliging toe. Google wil geen rechtszaken van gebruikers omdat zij nalatig zijn geweest bij het bouwen van, misschien wel het belangrijkste stuk software dat de hele wereld nu gebruikt (de Chrome browser).
Dat het op dit moment de meest gebruikte browser is (55%). Ja leuk, maar dat maakt het nog niet het belangrijkste stuk software.
Dat het op dit moment de meest gebruikte browser is (55%). Ja leuk, maar dat maakt het nog niet het belangrijkste stuk software.
Wat doen de meeste mensen op hun computer?
Voor praktisch elke gebruiker is het wel degelijk het belangrijkste stuk software.
Zonder OS doet dat stukje browser software anders niets.
Zonder OS doet dat stukje browser software anders niets.
Het feit dat Chrome op bijna ieder OS draait (Windows, Linux, OSX, Android, iOS, enz.) en dat men het ook op meerdere systemen gebruikt, geeft aan dat het OS minder relevant is dan de Chrome browser zelf.
Veel succes met het gebruiken van de Chrome browser op een apparaat zonder OS erop.
Wordt een willekeurige OS opeens toch wel belangrijk.

Beetje kip - ei discussie.
I.p.v. Chrome kan men ook andere browsers gebruiken en i.p.v. de ene OS zijn er nog tig andere OS-en

Dus als Chrome er morgen niet meer is/niet meer werkt, dan vergaat de wereld gelukkig niet, want dan gebruikt men wel een andere browser.
Mijn laatste antwoord in deze flame-war:
Het zal de user nu een worst wezen wel OS een machine draait, als de machine maar een variant van Chrome kan draaien. Daarmee is voor de meeste gebruikers het OS ondergeschikt aan de browser geworden.
Flame-war?
Nee hoor. Alleen die adoratie, daar heb ik wat tegen.

En dat de Chrome browser zoveel markt aandeel heeft, komt volgens mij alleen maar doordat het met Android als standaard browser wordt meegeleverd.
Niet, omdat het zo'n goede browser is. Dat is voor mij persoonlijk FF
Om het nu het belangrijkste te noemen.. het is maar een browser. Marktaandeel staat niet gelijk aan belangrijkheid. Ik vind software op mainframes bij banken, defensie, etc, toch iets belangrijker.
Denk hierbij ook aan meer geheugengebruik en kortere accuduur. Vooral dat laatste is een dingetje voor mensen die reizen.
Dit zal relatief eenvoudig geweest zijn voor Chrome aangezien ieder tabblad toch al in zijn eigen proces draaide.

Bij Firefox is dat niet het geval, vooral door de afweging tussen snelheid en geheugengebruik. Er is wel een project aan de gang om tabbladen verder te scheiden tussen processen. Hiervoor wordt hard aan de weg getimmerd om het geheugengebruik van individuele processen te verlagen.

Dat wil natuurlijk niet zeggen dat Firefox niet ook maatregelen heeft tegen Spectre. Zo zijn de JITs er op aangepast (zie de javascript.options.spectre opties in about:config).

[Reactie gewijzigd door Mitsuko op 12 juli 2018 11:19]

waarbij de laatste 1 procent wordt gebruikt om prestaties in de gaten te houden en zo nodig te verbeteren

zeggen ze hiermee dat ze 1% van de gebruikers (nog) niet beschermen tegen spectre? en gaan ze dit in de toekomst wel doen?
ik snap dat je metingen nodig hebt, maar ik vind dit een klein beetje raar.
Of dat ook in de iOS-versie gebeurt, vermeldt de zoekgigant niet.
Onder de kap is het gewoon Safari, dus dat zal puur van Apple en iOS afhangen.
Ik lag me stuk, dacht ik vorig jaar dat ik aan 16gb ram genoeg had en 64gb overkill is blijkt dat ik toch beter 64gb ram had moeten kopen. Nu is het echt onbetaalbaar geworden.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True