Deze pagina is vertaald door de Cloud Translation API.

Het verkrijgen van veiligheid en privacy door de cache te partitioneren

Eiji Kitamura

Over het algemeen kan caching de prestaties verbeteren door gegevens op te slaan, zodat toekomstige verzoeken om dezelfde gegevens sneller worden verwerkt. Een gecachte bron van het netwerk kan bijvoorbeeld een retourtje naar de server vermijden. Een gecacht rekenresultaat kan de tijd die nodig is om dezelfde berekening uit te voeren, overslaan.

In Chrome wordt het cachemechanisme op verschillende manieren gebruikt. HTTP-cache is daar een voorbeeld van.

Hoe de HTTP-cache van Chrome momenteel werkt

Vanaf versie 85 cachet Chrome bronnen die van het netwerk worden opgehaald, waarbij de bijbehorende bron-URL's als cachesleutel worden gebruikt. (Een cachesleutel wordt gebruikt om een gecachte bron te identificeren.)

Het volgende voorbeeld illustreert hoe één afbeelding in de cache wordt opgeslagen en in drie verschillende contexten wordt behandeld:

Cachesleutel: https://x.example/doge.png — **Cachesleutel** : { `https://x.example/doge.png` }

Een gebruiker bezoekt een pagina ( https://a.example ) die een afbeelding ( https://x.example/doge.png ) opvraagt. De afbeelding wordt opgevraagd via het netwerk en gecached met https://x.example/doge.png als sleutel.

Dezelfde gebruiker bezoekt een andere pagina ( https://b.example ) die dezelfde afbeelding ( https://x.example/doge.png ) opvraagt. De browser controleert zijn HTTP-cache om te zien of deze bron al in de cache staat, waarbij de URL van de afbeelding als sleutel wordt gebruikt. De browser vindt een match in zijn cache en gebruikt daarom de gecachte versie van de bron.

Het maakt niet uit of de afbeelding vanuit een iframe wordt geladen. Als de gebruiker een andere website ( https://c.example ) met een iframe ( https://d.example ) bezoekt en het iframe dezelfde afbeelding opvraagt ( https://x.example/doge.png ), kan de browser de afbeelding nog steeds vanuit de cache laden, omdat de cachesleutel voor alle pagina's hetzelfde is.

Dit mechanisme werkt al lange tijd goed vanuit prestatieperspectief. De tijd die een website nodig heeft om te reageren op HTTP-verzoeken, kan echter onthullen dat de browser in het verleden dezelfde bron heeft gebruikt, wat de browser kwetsbaar maakt voor beveiligings- en privacyaanvallen, zoals de volgende:

Detecteren of een gebruiker een specifieke site heeft bezocht : Een tegenstander kan de browsegeschiedenis van een gebruiker detecteren door te controleren of de cache een bron heeft die specifiek is voor een bepaalde site of een groep sites.
Cross-site zoekopdracht-aanval : Een aanvaller kan detecteren of een willekeurige tekenreeks in de zoekresultaten van de gebruiker staat door te controleren of er een afbeelding met 'geen zoekresultaten' die door een bepaalde website wordt gebruikt, in de cache van de browser staat.
Cross-site tracking : De cache kan worden gebruikt om cookie-achtige identificatiegegevens op te slaan als een cross-site trackingmechanisme.

Om deze risico's te beperken, zal Chrome vanaf Chrome 86 zijn HTTP-cache partitioneren.

Welk effect heeft cachepartitionering op de HTTP-cache van Chrome?

Met cachepartitionering worden gecachte bronnen naast de bron-URL voorzien van een nieuwe "Netwerkisolatiesleutel". De Netwerkisolatiesleutel bestaat uit de site op het hoogste niveau en de site van het huidige frame.

Kijk nog eens naar het vorige voorbeeld om te zien hoe cachepartitionering in verschillende contexten werkt:

Cachesleutel { https://a.example, https://a.example, https://x.example/doge.png} — **Cachesleutel** : { `https://a.example` , `https://a.example` , `https://x.example/doge.png` }

Een gebruiker bezoekt een pagina ( https://a.example ) die een afbeelding ( https://x.example/doge.png ) opvraagt. In dit geval wordt de afbeelding opgevraagd via het netwerk en gecached met een tuple bestaande uit https://a.example (de site op het hoogste niveau), https://a.example (de site in het huidige frame) en https://x.example/doge.png (de bron-URL) als sleutel. (Houd er rekening mee dat wanneer de bronaanvraag afkomstig is van het frame op het hoogste niveau, de site op het hoogste niveau en de site in het huidige frame in de netwerkisolatiesleutel hetzelfde zijn.)

Dezelfde gebruiker bezoekt een andere pagina ( https://b.example ) die dezelfde afbeelding ( https://x.example/doge.png ) opvraagt. Hoewel in het vorige voorbeeld dezelfde afbeelding werd geladen, zal dit geen cachehit zijn omdat de sleutel niet overeenkomt.

De afbeelding wordt opgevraagd bij het netwerk en in de cache opgeslagen met behulp van een tuple bestaande uit https://b.example , https://b.example en https://x.example/doge.png als sleutel.

De gebruiker keert nu terug naar https://a.example , maar deze keer is de afbeelding ( https://x.example/doge.png ) ingebed in een iframe. In dit geval is de sleutel een tuple met https://a.example , https://a.example en https://x.example/doge.png en vindt er een cachehit plaats. (Merk op dat wanneer de site op het hoogste niveau en de iframe dezelfde site zijn, de resource die met het frame op het hoogste niveau in de cache is opgeslagen, kan worden gebruikt.)

De gebruiker is terug op https://a.example , maar deze keer wordt de afbeelding gehost in een iframe van https://c.example .

In dit geval wordt de afbeelding gedownload van het netwerk omdat er geen bron in de cache is die overeenkomt met de sleutel bestaande uit https://a.example , https://c.example en https://x.example/doge.png .

Wat als het domein een subdomein of een poortnummer bevat? De gebruiker bezoekt https://subdomain.a.example , dat een iframe ( https://c.example:8080 ) bevat die de afbeelding opvraagt.

Omdat de sleutel wordt aangemaakt op basis van "scheme://eTLD+1", worden subdomeinen en poortnummers genegeerd. Daardoor ontstaat er een cachehit.

Wat als het iframe meerdere keren is genest? De gebruiker bezoekt https://a.example , dat een iframe ( https://b.example ) insluit, dat weer een ander iframe ( https://c.example ) insluit, dat uiteindelijk de afbeelding opvraagt.

Omdat de sleutel afkomstig is uit het bovenste frame ( https://a.example ) en het frame direct waarin de resource wordt geladen ( https://c.example ), ontstaat er een cachehit.

Veelgestelde vragen

Is het al ingeschakeld in mijn Chrome? Hoe kan ik dit controleren?

De functie wordt uitgerold tot eind 2020. Zo controleert u of uw Chrome-instantie deze al ondersteunt:

Open chrome://net-export/ en klik op Start Logging to Disk .
Geef aan waar u het logbestand op uw computer wilt opslaan.
Surf een minuutje op internet in Chrome.
Ga terug naar chrome://net-export/ en klik op Stop Logging .
Ga naar https://netlog-viewer.appspot.com/#import .
Klik op 'Kies bestand' en geef het logbestand door dat u hebt opgeslagen.

U ziet de uitvoer van het logbestand.

Zoek op dezelfde pagina naar SplitCacheByNetworkIsolationKey . Als dit wordt gevolgd door Experiment_[****] , is HTTP-cachepartitionering ingeschakeld in Chrome. Als dit wordt gevolgd door Control_[****] of Default_[****] , is het niet ingeschakeld.

Hoe kan ik HTTP-cachepartitionering testen op mijn Chrome?

Om HTTP-cachepartitionering op uw Chrome-platform te testen, moet u Chrome starten met een opdrachtregelvlag: --enable-features=SplitCacheByNetworkIsolationKey . Volg de instructies in Chromium uitvoeren met vlaggen om te leren hoe u Chrome start met een opdrachtregelvlag op uw platform.

Moet ik als webontwikkelaar actie ondernemen naar aanleiding van deze wijziging?

Dit is geen ingrijpende wijziging, maar het kan wel prestatieproblemen opleveren voor bepaalde webservices.

Bedrijven die bijvoorbeeld grote hoeveelheden zeer cachebare bronnen op meerdere websites aanbieden (zoals lettertypen en populaire scripts), kunnen een toename in hun verkeer zien. Ook kunnen gebruikers van dergelijke diensten er afhankelijker van worden.

(Er is een voorstel om gedeelde bibliotheken op een privacybeschermende manier mogelijk te maken, genaamd Web Shared Libraries ( presentatievideo ), maar dit is nog in overweging.)

Wat is de impact van deze gedragsverandering?

Het totale cache-misspercentage neemt met ongeveer 3,6% toe, de wijzigingen in de FCP (First Contentful Paint) zijn bescheiden (~0,3%) en het totale aantal bytes dat vanuit het netwerk wordt geladen, neemt met ongeveer 4% toe. Meer informatie over de impact op de prestaties vindt u in de uitleg over HTTP-cachepartitionering .

Is dit gestandaardiseerd? Gedragen andere browsers zich anders?

"HTTP-cachepartities" zijn gestandaardiseerd in de fetch-specificatie, hoewel browsers zich anders gedragen:

Chrome : gebruikt het hoogste schema://eTLD+1 en het frameschema://eTLD+1
Safari : gebruikt top-level eTLD+1
Firefox : van plan om te implementeren met het toplevelschema://eTLD+1 en overweegt een tweede sleutel op te nemen zoals in Chrome

Hoe wordt er omgegaan met de opbrengst van werknemers?

Dedicated workers gebruiken dezelfde sleutel als hun huidige frame. Serviceworkers en shared workers zijn complexer omdat ze gedeeld kunnen worden tussen meerdere sites op het hoogste niveau. De oplossing hiervoor wordt momenteel besproken.