Speicherpartitionierung

Um bestimmte Arten von websiteübergreifendem Tracking bei Seitenkanälen zu verhindern, werden in Chrome die meisten Speicher- und Kommunikations-APIs in Drittanbieterkontexten partitioniert.

Implementierungsstatus

Die Funktion ist für alle Nutzer in Chrome 115 und höher aktiviert. Der Vorschlag zur Speicherpartitionierung steht für weitere Diskussionen offen.

Was ist die Speicherpartitionierung?

Um bestimmte Arten von websiteübergreifendem Tracking bei Seitenkanälen zu verhindern, partitioniert Chrome Speicher- und Kommunikations-APIs im Zusammenhang mit Drittanbietern.

Ohne Speicherpartitionierung kann eine Website Daten von verschiedenen Websites zusammenführen, um Nutzer im Web zu verfolgen. Außerdem kann die eingebettete Website mithilfe von Side-Channel-Techniken wie Timing-Angriffen, XS-Leaks und COSI bestimmte Status des Nutzers auf der Website der obersten Ebene ableiten.

Bisher wurde der Speicherplatz nur nach Herkunft sortiert. Wenn also ein Iframe von example.com auf a.com und b.com eingebettet ist, kann er Informationen zu Ihren Browsergewohnheiten auf diesen beiden Websites erhalten, indem eine ID gespeichert und erfolgreich aus dem Speicher abgerufen wird. Wenn die Drittanbieter-Speicherpartitionierung aktiviert ist, befindet sich der Speicher für example.com in zwei verschiedenen Partitionen, eine für a.com und die andere für b.com.

Partitionierung bedeutet im Allgemeinen, dass Daten, die über Speicher-APIs wie Local Storage und IndexedDB in einem Iframe gespeichert werden, nicht mehr für alle Kontexte im selben Ursprung zugänglich sind. Stattdessen sind die Daten nur für Kontexte mit demselben Ursprung und derselben Website der obersten Ebene verfügbar.

Vorher

Diagramm von Speicher-APIs ohne Partitionierung
Vor der Speicherpartitionierung kann beispiel.de Daten schreiben, wenn es in a.com eingebettet ist, und sie dann lesen, wenn es in b.com eingebettet ist.

Nachher

Diagramm von Speicher-APIs mit Partitionierung.
Nach der Speicherpartitionierung kann „beispiel.de“, wenn es in „b.de“ eingebettet ist, nicht auf den Speicher von „beispiel.de“ zugreifen, wenn es in „a.de“ eingebettet ist.

Speicherpartitionierung in verketteten iFrames

Wenn ein Iframe einen Iframe enthält, wird es komplizierter. Dies gilt insbesondere, wenn derselbe Ursprung an mehreren Stellen in der Kette vorhanden ist.

Beispiel: A1 enthält einen Iframe für B, der einen Iframe für A2 enthält. A1 und A2 befinden sich auf derselben Website. Wenn bei der Partitionierung nur die Kontexte der obersten und der aktuellen Ebene berücksichtigt werden, könnte Iframe A2 als selbst gehostet betrachtet werden, da er sich trotz des dazwischen liegenden Drittanbieter-Iframes (B) auf derselben Website wie der Iframe der obersten Ebene (A1) befindet. Dies könnte A2 Sicherheitsrisiken wie Clickjacking aussetzen, wenn A2 standardmäßig Zugriff auf nicht partitionierten Speicher hätte.

Um dies zu vermeiden, enthält Chrome als Teil des Speicherpartitionsschlüssels ein zusätzliches „Vorgänger-Bit“, das gesetzt wird, wenn ein Dokument zwischen dem aktuellen Kontext und dem Kontext der obersten Ebene websiteübergreifend ist. In diesem Fall ist Website B websiteübergreifend. Das Bit wird also für A2 festgelegt und der Speicher wird von A1 partitioniert.

Wenn die Kette keinen websiteübergreifenden Kontext enthält, wird der Speicher nicht partitioniert. Beispiel: Die Website A1 mit einem iFrame für A2, der einen iFrame für A3 enthält, wird nicht für A1, A2 oder A3 partitioniert, da sich alle auf derselben Website befinden.

Für Websites, die einen nicht partitionierten Zugriff über verkettete iframes benötigen, erprobt Chrome die Erweiterung der Storage Access API, um diesen Anwendungsfall zu ermöglichen. Da die Storage Access API erfordert, dass die geframete Website die API explizit aufruft, wird das Clickjacking-Risiko verringert.

Aktualisierte APIs

APIs, die von der Partitionierung betroffen sind, können in die folgenden Gruppen unterteilt werden:

Storage APIs

  • Kontingentsystem
    Mit dem Quota-System wird festgelegt, wie viel Speicherplatz für die Speicherung zugewiesen wird. Das Kontingentsystem verwaltet jede Partition als separaten Bucket, um zu bestimmen, wie viel Speicherplatz zulässig ist und wann er gelöscht wird.
    Die navigator.storage.estimate() gibt die Informationen zur Partition zurück. Chrome-spezifische APIs wie window.webkitStorageInfo und navigator.webkitTemporaryStorage werden eingestellt.
    IndexedDB und Cache-Speicher verwenden das neue partitionierte Kontingentsystem.
  • Web Storage API
    Die Web Storage API bietet Mechanismen, mit denen Browser Schlüssel/Wert-Paare speichern können. Es gibt zwei Mechanismen: lokaler Speicher und Sitzungsspeicher. Sie werden derzeit nicht kontingentverwaltet, aber weiterhin partitioniert.
  • Origin Private File System
    Mit der File System Access API kann eine Website Änderungen direkt in Dateien und Ordnern auf dem Gerät lesen oder speichern, nachdem der Nutzer Zugriff gewährt hat. Mit dem Origin Private File System kann ein Ursprung private Inhalte auf der Festplatte speichern, auf die der Nutzer leicht zugreifen kann. Die Inhalte sind partitioniert.
  • Storage Bucket API
    Die Storage Bucket API wird für den Storage Standard entwickelt, der verschiedene Speicher-APIs wie IndexedDB und localStorage mithilfe eines neuen Konzepts namens „Buckets“ konsolidiert. Die in den Buckets gespeicherten Daten und die zugehörigen Metadaten werden partitioniert.
  • Clear-Site-Data-Header
    Wenn der Clear-Site-Data-Header in die Antwort aufgenommen wird, kann ein Server das Löschen der im Browser des Nutzers gespeicherten Daten anfordern. Cache, Cookies und DOM-Speicher können gelöscht werden. Mit der Überschrift wird nur der Speicherplatz innerhalb einer Partition gelöscht.
  • Blob-URL-Speicher
    Ein Blob ist ein Objekt, das zu verarbeitende Rohdaten enthält. Für den Zugriff auf die Ressource kann eine Blob-URL generiert werden. Blob-URL-Stores werden nicht partitioniert. Um einen Anwendungsfall für die Navigation in einem Kontext der obersten Ebene zu einer beliebigen Blob-URL zu unterstützen (Diskussion), kann der Blob-URL-Speicher nach dem Cluster des Agents statt nach der Website der obersten Ebene partitioniert werden. Diese Funktion ist noch nicht für Tests verfügbar und der Partitionierungsmechanismus kann sich in Zukunft ändern.

Kommunikations-APIs

Neben Speicher-APIs werden auch Kommunikations-APIs partitioniert, die es einem Kontext ermöglichen, über Herkunftsgrenzen hinweg zu kommunizieren. Die Änderungen betreffen hauptsächlich APIs, die das Erkennen anderer Kontexte über Broadcasting oder Rendezvous mit demselben Ursprung ermöglichen.

Für die folgenden Kommunikations-APIs können iframes von Drittanbietern nicht mehr mit dem Kontext desselben Ursprungs kommunizieren:

  • Broadcast-Kanal
    Die Broadcast Channel API ermöglicht die Kommunikation zwischen Browserkontexten (Fenster, Tabs oder Iframes) und Workern desselben Ursprungs.
    Websiteübergreifender Iframe postMessage(), bei dem die Beziehung zwischen den Kontexten klar definiert ist, soll nicht geändert werden.
  • SharedWorker
    Die SharedWorker API stellt einen Worker bereit, auf den über mehrere Browserkontexte derselben Quelle zugegriffen werden kann.
  • Websperren
    Mit der Web Locks API kann Code, der in einem Tab oder Worker desselben Ursprungs ausgeführt wird, eine Sperre für eine freigegebene Ressource erwerben, während eine bestimmte Arbeit ausgeführt wird.

Service Worker API

Die Service Worker API bietet die Schnittstelle für die Ausführung von Aufgaben im Hintergrund. Websites erstellen persistente Registrierungen, die einen neuen Worker-Kontext zum Beantworten von Ereignissen erstellen. Dieser Worker kann mit jedem Kontext desselben Ursprungs kommunizieren. Außerdem kann die Service Worker API den Zeitpunkt von Navigationsanfragen ändern, was zu potenziellen Website-übergreifenden Datenlecks wie History-Sniffing führen kann.

Daher werden Service Worker, die über einen Drittanbieterkontext registriert sind, partitioniert.

Erweiterungs-APIs

Erweiterungen sind Programme, mit denen Nutzer ihre Browsernutzung anpassen können.

Erweiterungsseiten (Seiten mit einem chrome-extension://-Schema) können auf Websites im Web eingebettet werden. In diesen Fällen haben sie weiterhin Zugriff auf ihre Partition auf oberster Ebene. Auf diesen Seiten können auch andere Websites eingebettet werden. In diesem Fall haben diese Websites Zugriff auf ihre Partition der obersten Ebene, sofern die Erweiterung Hostberechtigungen für diese Website hat.

Weitere Informationen finden Sie in der Dokumentation zur Erweiterung.

Demo: Speicherpartitionierung testen

Demo-Website: https://storage-partitioning-demo-site-a.glitch.me/

Screenshot der Demo-Website mit grünen Häkchen links und roten Kreuzen rechts für jeden Test
Screenshot der Demo mit der Ausgabe für einen Browser mit Speicherpartitionierung links und ohne Speicherpartitionierung rechts.

In der Demo werden zwei Websites verwendet: Website A und Website B.

  • Wenn Sie Website A im Kontext der obersten Ebene besuchen, werden Daten mit verschiedenen Speichermethoden festgelegt.
  • Auf Website B wird eine Seite von Website A eingebettet. Bei diesem Einbetten wird versucht, die zuvor festgelegten Speicheroptionen zu lesen.
  • Wenn Website A in Website B eingebettet ist, hat sie keinen Zugriff auf diese Daten, wenn der Speicher partitioniert ist. Die Lesevorgänge schlagen daher fehl.
  • In der Demo wird der Erfolg oder Misserfolg jeder Leseoperation verwendet, um anzuzeigen, ob Daten partitioniert sind.

Derzeit können Sie die Speicherpartitionierung in Chrome mithilfe der --disable-features=ThirdPartyStoragePartitioning-Befehlszeilenoption deaktivieren.

Sie können auch andere Browser auf die gleiche Weise testen, um den Partitionsstatus zu sehen.

Feedback geben und erhalten