Skal du deaktivere webstedsisolering i Google Chrome

Nu har du sikkert hørt om ‘Spectre’, den ildevarslende døbte sikkerhedsfejl, der påvirker næsten alle moderne CPU’er. Og det med rette, da sårbarheden drejer sig om ondsindede applikationer og websteder, der får adgang til data fra områder, hvor de egentlig ikke burde. For at klare dette problem specifikt har browsere udviklet forskellige sikkerhedsmekanismer, og en sådan Chrome-specifik implementering er Site Isolation.

Først introduceret i Chrome v63 som en valgfri sikkerhedsfunktion, kører Site Isolation nu som standard siden version 67. Teknisk set er den ret dygtig til at afbøde spekulative eksekveringsangreb (som Spectre er baseret på) på grund af de sandkasseprocesser, som den bruger.

Men ligesom med alt godt, har det en pris – for at være specifik, ydeevne. Så ville deaktivering af webstedsisolering forbedre, hvordan Chrome fungerer? Er det værd at bytte med sikkerhed? Lad os finde ud af det.

Spøgelse og lokalitetsisolation

Ligesom enhver anden browser giver Google Chrome dig mulighed for at åbne flere websteder ved hjælp af forskellige faner. Før implementeringen af ​​Site Isolation brugte faner til at dele fælles processer – hvilket giver mening, da duplikering af opgaver ville være spild af systemressourcer. Det er dog en situation, der er ideel til, at et ondsindet angreb kan opstå baseret på mangelfuldt CPU-design — Spectre.

Moderne mikroprocessorer bruger spekulativ eksekvering til at forudindlæse data fra systemhukommelsen til den betydeligt hurtigere CPU-cache som et middel til at forbedre den samlede ydeevne. Dette giver dog en unik mulighed for ondsindet kode til at bede CPU’en om at hente følsomme data ind i sin cache ved at udnytte delte processer. Når først dataene er i CPU-cachen, efterlades de ubeskyttet (i modsætning til systemhukommelsen) og kan nemt stjæles.

Antag, at du har et par faner åbne – den ene med din bankkonto og den anden med et tilfældigt websted. I teorien kan sidstnævnte, forudsat at det har ondsindede hensigter, dykke ned i CPU-cachen, der bruges af den førstnævnte fane, og derefter indlæse og læse information lige fra login-detaljer til kryptografiske nøgler.

Selvom det er ret svært at forestille sig, at en sådan hændelse finder sted på grund af den begrænsede CPU-cache (som kun er en lille brøkdel sammenlignet med systemhukommelse), bestemmer ondsindet kode i stedet præcis, hvilke data der skal stjæles ved at sammenligne forskellen mellem CPU-adgangshastigheder. Når alt kommer til alt, hvis tingene er hurtigere end normalt, skyldes det, at dataene allerede er i CPU-cachen ved nøjagtige spekulationer.

Efter opdagelsen af ​​Spectre-sårbarheden begyndte browsere at bruge forskellige løsninger (såsom timere med lavere opløsning for at mindske nøjagtigheden af ​​at bestemme CPU-adgangshastigheder) for at afbryde målrettede angreb. De er dog ikke et perfekt middel til at imødegå Spectre-baserede trusler, deraf årsagen til Site Isolation.

Site Isolation, som navnet antyder, isolerer fuldstændigt faner fra hinanden ved at skabe separate processer for alle iframes (indlejrede eksterne links), inklusive dem, der er fælles for andre faner. Da delte processer spiller en stor rolle i at hjælpe ondsindet kode med at overvåge og læse information fra andre faner, fungerer Site Isolations brug af uafhængige processer godt til at afbøde sådanne sårbarheder.

Ser vi på vores tidligere eksempel, med Site Isolation slået til, kører din bankkontoportal på en helt anden proces og deler intet, der ligner den anden fane. Denne ‘isolation’ reducerer muligheden for at stjæle information i tilfælde af et brud til et minimum.

Øget hukommelsesomkostninger

Så du må spekulere på, om Site Isolation koster ydeevnen på grund af den ekstra systemhukommelse, der bruges af hver uafhængig proces – browserfane. Ifølge Google Online Security Blog bruger sikkerhedsimplementeringen op til 10-13 % mere RAM, end hvis funktionen ikke er aktiv i første omgang.

Lad os se, hvor nøjagtigt dette tal er i praksis. Uden webstedsisolering aktiveret viser skærmbilledet nedenfor et par websteder, der bruger mange lignende iframes. Kun de to faner har separate igangværende opgaver uden uafhængige processer for nogen af ​​iframes.

Bemærk:

De samme par faner, med Site Isolation aktiveret, vises på det næste skærmbillede. Som du kan se, er der en betydelig stigning i antallet af yderligere processer på grund af de iframes, der bruges af hvert websted. Yderligere er lignende processer yderligere opdelt i to for at mindske chancerne for et vellykket spekulativt henrettelsesangreb. Hvis du gør regnestykket (se bort fra browser- og GPU-procesopgaverne), ender begge sider med at bruge omkring 33 % mere hukommelse.

Hukommelsesforbruget er væsentligt over, hvad der er angivet af Google. Overvej dog tallet 10-13 % mere af et langsigtet gennemsnit. Websteder, og endda individuelle websider, varierer i antallet af processer og hukommelse, der kræves fra tid til anden. Derfor kan ovenstående scenarie betragtes som en outlier.

Uanset hvad resulterer Site Isolation i moderate eller i dette tilfælde betydelige stigninger i hukommelsesomkostningerne.

Sikkerhed vs. ydeevne

Deaktivering af Site Isolation resulterer i et fald i hukommelsesforbruget og øger muligvis ydeevnen på low-end enheder. Chrome er dog ret dygtig til at administrere tilgængelig hukommelse ved at suspendere ubrugte faner. I betragtning af, at hukommelsesforbruget varierer drastisk fra websted til websted, er der ikke noget endeligt svar. På enheder med høj systemhukommelse bør forskellene i ydeevne være ubetydelige.

Tip: Derudover kan du også påtage dig selv at styre faner manuelt fra at tilstoppe hukommelsen ved at bruge udvidelser som The Great Discarder og The Great Suspender

Men her er fangsten. På grund af implementeringen af ​​Site Isolation, er det meningen, at Chrome skal droppe allerede eksisterende modforanstaltninger mod Spectre-angreb over tid. Derfor vil deaktivering af det forårsage endnu mere eksponering for ondsindede angreb.

Når man vejer de to op, gør de potentielle sårbarheder forårsaget af Spectre, kombineret med den stadigt stigende brug af personlige data, at slå Site Isolation fra til en dårlig idé. Medmindre du surfer på en low-end maskine og ikke gør brug af personlige data overhovedet, bør du først da overveje at deaktivere denne vigtige sikkerhedsfunktion.

Deaktivering af webstedsisolering

Deaktivering af Site Isolation udsætter din computer for betydelige sikkerhedstrusler. Men hvis du ønsker at gå videre og deaktivere funktionen, er nedenfor de specifikke trin til at gøre det.

Advarsel:

Trin 1: Skriv chrome://flags på en ny fane, og tryk derefter på Enter for at få adgang til Chrome-eksperimentelle flag.

Trin 2: Skriv Site Isolation i søgefeltet, og tryk derefter på Enter.

Trin 3: Du bør se to Chrome-flag mærket Strict Site Isolation og Site Isolation Trial Opt Out.

• Indstil flaget Strict Site Isolation til Deaktiveret. Specifikke enheder kan have dette indstillet til Deaktiveret som standard – hvis det er tilfældet, skal du ikke gøre noget.
• Indstil flaget for fravalg af prøveversion af webstedsisolation til fravalg (anbefales ikke).

Klik derefter på Genstart nu for at anvende ændringerne.

Trin 5: Site Isolation er nu deaktiveret. For at bekræfte skal du skrive chrome://process-internals i en ny fane og derefter trykke på Enter.

Site Isolation Mode bør læses som Deaktiveret for at angive bekræftelse. For at aktivere Site Isolation på et senere tidspunkt skal du gå tilbage og ændre flagene til den måde, de var før, og genstarte Chrome.

Nej, det er ikke risikoen værd

Det er ikke berettiget at deaktivere en kritisk Chrome-sikkerhedsfunktion såsom Site Isolation for at reducere hukommelsesforbruget. Især i betragtning af, hvordan hvert websted bruger hukommelsen forskelligt. Så enhver marginal præstationsgevinst til de potentielle omkostninger ved dine personlige oplysninger bør ikke efterlyses. Hvis du kæmper med ydeevnen, kan du altid overveje at bruge en alternativ browser som Firefox Quantum, der har et meget lavere hukommelsesfodaftryk sammenlignet med Chrome, før du gør noget overilet.