State Partitioning

Browser speichern den clientseitigen Zustand traditionell durch den Ursprung (oder manchmal die registrierbare Domäne) des Standorts, von dem eine Ressource geladen wurde. Zum Beispiel werden die Cookies, localStorage-Objekte und Caches, die einem iframe zur Verfügung stehen, das von https://example.com/hello.html geladen wird, von example.com gespeichert. Dies gilt unabhängig davon, ob der Browser derzeit Ressourcen von dieser Domäne als Erstanbieter-Ressourcen oder als eingebettete Drittanbieter-Ressourcen lädt. Tracker haben diesen zustandsabhängigen Mechanismus für die verfolgung von Benutzern über Websites hinweg genutzt und darauf zugegriffen. Das untenstehende Beispiel zeigt, wie example.com seinen zustandsabhängigen Mechanismus (in diesem Fall Cookies) nutzen kann, um einen Benutzer sowohl auf seiner eigenen Seite als auch auf A.example und B.example zu verfolgen.

Firefox' frühere Cookie-Richtlinien versuchen, das Verfolgung zu mildern, indem sie den Zugriff auf einige Speicher-APIs (z.B. Cookies und localStorage) für bestimmte Domänen unter bestimmten Bedingungen blockieren. Zum Beispiel wird unsere "Blockiere alle Drittanbieter-Cookies"-Richtlinie alle Domänen daran hindern, auf bestimmte Speicher-APIs zuzugreifen, wenn sie im Drittanbieter-Kontext geladen werden. Unsere aktuelle Cookie-Standardrichtlinie blockiert den Zugriff im Drittanbieter-Kontext nur für Domänen, die als Tracker klassifiziert sind.

State Partitioning ist ein anderer Ansatz zur Verhinderung der Verfolgung über Websites hinweg. Anstatt den Zugriff auf bestimmte APIs in einem Drittanbieter-Kontext zu blockieren, bietet Firefox eingebetteten Ressourcen einen separaten Speicherbereich für jede oberste Website. Genauer gesagt speichert Firefox alle clientseitigen Zustände doppelt, nach dem Ursprung der geladenen Ressource und nach der obersten Seite. In den meisten Fällen ist die oberste Seite das Schema und eTLD+1 der obersten Seite, die vom Benutzer besucht wird.

Im untenstehenden Beispiel ist example.com in A.example und B.example eingebettet. Da jedoch der Speicher partitioniert ist, gibt es drei unterschiedliche Speicherbereiche (statt einem). Der Tracker kann weiterhin auf den Speicher zugreifen, aber da jeder Speicherbereich zusätzlich unter der obersten Seite gespeichert wird, werden die zugänglichen Daten auf A anders sein als die auf B. Dies wird einen Tracker daran hindern, eine Kennung in seinen Cookies zu speichern, wenn er direkt besucht wird, und diese Kennung dann abzurufen, wenn er in andere Websites eingebettet ist.

Die Privacy Community Group hat einen Arbeitsgegenstand für Client-Side Storage Partitioning. Dies dient als Überblick über die Standardisierungsbemühungen für die Speicherpartitionierung in den betroffenen individuellen Standards. Wir beabsichtigen, unsere State Partitioning-Implementierung mit diesen Bemühungen abzugleichen, sobald der Arbeitsgegenstand standardisiert ist.

• Netzwerkpartitionierung: Seit Firefox 85 für alle Benutzer standardmäßig aktiviert.
• Dynamische Partitionierung:
  • Seit Firefox 86: Aktiviert für Benutzer, die „Strenge“ Datenschutzmaßnahmen aktiviert haben.
  • Seit Firefox 90: Aktiviert im privaten Browsing.

Um zu verhindern, dass über JavaScript zugängliche Speicher-APIs zur Verfolgung über Websites hinweg verwendet werden, wird der zugängliche Speicher nach der obersten Website partitioniert. Dieser Mechanismus bedeutet im Allgemeinen, dass ein Drittanbieter, der in einer obersten Website eingebettet ist, nicht auf Daten zugreifen kann, die unter einer anderen obersten Website gespeichert sind.

• localStorage
• sessionStorage
• DOM Cache
• IndexedDB
• Broadcast Channel
• Shared Workers
• Service Workers

Netzwerkbezogene APIs sind nicht dazu gedacht, dass Websites Daten speichern, aber sie können für die Verfolgung über Websites hinweg missbraucht werden. Daher werden die folgenden Netzwerk-APIs und -Caches dauerhaft durch die oberste Website partitioniert.

• HTTP Cache
• Bild-Cache
• Favicon-Cache
• Verbindungspooling
• Stylesheet-Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftart-Cache
• HSTS
• OCSP
• Intermediate CA Cache
• TLS-Client-Zertifikate
• TLS-Sitzungs-IDs
• Prefetch
• Preconnect
• CORS-preflight Cache
• WebRTC deviceID

Im Allgemeinen, wenn zugänglicher Speicher durch die oberste Website partitioniert ist, kann der Zugriff auf die unpartitionierten Cookies eines Drittanbieters dennoch gewährt werden, wenn die Storage Access API unterstützt wird:

• unter Verwendung der Storage Access API.
• automatisch, z. B. für Drittanbieter, die ein föderiertes Login ermöglichen.

Details über automatische Gewährungen finden Sie im Abschnitt Heuristik des Speicherkontrollzugriffs.

• Cookies

Um die Web-Kompatibilität zu verbessern, umfasst Firefox derzeit einige Heuristiken, um Drittanbietern, die Benutzerinteraktionen erhalten, automatisch nicht partitionierten Zugang zu Cookies zu gewähren. Diese Heuristiken sollen es einigen auf dem Web weit verbreiteten Drittanbieter-Integrationen ermöglichen, weiterhin zu funktionieren.

Opener-Heuristiken

• Wenn ein partitionierter Drittanbieter ein Pop-up-Fenster öffnet, das Opener-Zugriff auf das Ursprungdokument hat, wird dem Drittanbieter der Speicherzugriff für seinen Einbettungscode für 30 Tage gewährt.
• Wenn ein Erstanbieter a.example ein Drittanbieter-Pop-up b.example öffnet, wird b.example der Drittanbieter-Speicherzugriff auf a.example für 30 Tage gewährt.

Umleitungs-Heuristiken

• Wenn eine Website b.example auf a.example umleitet, dann erhält b.example Speicherzugriff auf seinen Einbettungscode a.example, wenn sowohl a.example als auch b.example innerhalb der letzten 10 Minuten besucht und genutzt wurden. Dieser Speicherzugriff wird für 15 Minuten gewährt.
• Wenn ein Tracker tracker.example (wie von der Enhanced Tracking Protection klassifiziert) auf einen Nicht-Tracker a.example umleitet und tracker.example innerhalb der letzten 45 Tage eine Benutzerinteraktion als Erstanbieter erhalten hat, erhält tracker.example Speicherzugriff auf a.example für 15 Minuten.

Drittanbieter-Frames können document.requestStorageAccess verwenden, um nicht partitionierten Zugriff auf Cookies über die Storage Access API anzufordern. Sobald dies gewährt wird, erhält der anfragende Drittanbieter Zugriff auf seine vollständigen Erstanbieter-Cookies (d. h. die Cookies, auf die er Zugriff hätte, wenn er als Erstanbieter besucht wird).

Wir ermutigen Webseitenbetreiber, ihre Sites zu testen, insbesondere diejenigen, die auf Drittanbieterinhalte setzen. Es gibt mehrere Funktionen in Firefox, die das Testen erleichtern.

Hier ist ein Überblick über die Nachrichten, die an die Webkonsole gesendet werden, wenn Sie mit dem Speicher in einem Drittanbieter-Kontext interagieren. In den folgenden Beispielen ist a.example die oberste Website, die den Drittanbieter-Frame b.example einbettet.

Wenn ein Drittanbieter-iframe den Speicherzugriff auf den übergeordneten Kontext erhält, setzt Firefox eine Berechtigung. Um den Zugriff zu widerrufen, können Sie die Berechtigung über das Site Information Panel im Abschnitt Berechtigungen unter "Webseiten-Berechtigungen" im Bereich „Cookies über Websites hinweg“ löschen.

Web-Kompatibilitätsfunktionen deaktivieren

Das Setzen von privacy.antitracking.enableWebcompat auf false wird alle ETP- und State Partitioning-Web-Kompatibilitätsfunktionen deaktivieren. Das Deaktivieren dieser Funktionen kann beim Testen nützlich sein, um sicherzustellen, dass Ihre Website vollständig mit dem State Partitioning-Mechanismus in Firefox kompatibel ist und sie nicht auf vorübergehende Heuristiken angewiesen ist.

Funktionen, die durch die Voreinstellung deaktiviert werden, umfassen:

• Heuristiken des Speicherkontrollzugriffs: Nicht-partitionierter Zugriff auf Cookies kann nur über die Storage Access API erworben werden.
• Automatische Gewährung des Speicherzugriffs: document.requestStorageAccess wird den Benutzer immer zur Bestätigung auffordern.
• SmartBlock-Funktion "auf Einschalten freischalten", die bestimmte Tracker erlaubt, wenn Benutzer mit ihnen interagieren.
• Alle vorübergehenden Anti-Tracking-Ausnahmen, die Websites über den Mechanismus zum Überspringen von Listen gewährt werden.

Heuristiken deaktivieren

Die folgenden Voreinstellungen können verwendet werden, um einzelne Heuristiken des Speicherkontrollzugriffs über den Config-Editor zu deaktivieren:

• Aktivieren / Deaktivieren der Umleitungs-Heuristiken: privacy.restrict3rdpartystorage.heuristic.recently_visited, privacy.restrict3rdpartystorage.heuristic.redirect
• Aktivieren / Deaktivieren der Fensteröffnungs-Heuristiken: privacy.restrict3rdpartystorage.heuristic.window_open, privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction

Netzwerkpartitionierung deaktivieren

Die Netzwerkpartitionierung kann mit der Voreinstellung privacy.partition.network_state deaktiviert werden.

Dynamische State-Partitionierung deaktivieren

Um die dynamische Speicherpartitionierung für alle Websites zu deaktivieren, können Sie die Voreinstellung network.cookie.cookieBehavior verwenden:

Bestimmte Ursprünge von der Partitionierung ausnehmen

Die dynamische State-Partitionierung kann auch für bestimmte Ursprünge mit der Voreinstellung privacy.restrict3rdpartystorage.skip_list deaktiviert werden. Diese Voreinstellung enthält eine liste von Ursprüngen, die ein Komma getrennt sind. Der Wert der Voreinstellung sollte folgendes Format haben: first-party_origin_1,third-party_origin_1;first-party_origin_2,third-party_origin_2;....

Beispielsweise, um die Partitionierung für tracker.example auf example.com oder social.example auf news.example zu deaktivieren, würden Sie die Voreinstellung folgendermaßen setzen:

https://example.com,https://tracker.example;https://news.example,https://social.example

Sie können * als Platzhalter für entweder den ersten oder den dritten Anbieter verwenden. Zum Beispiel, um die Partitionierung für videos.example auf allen Websites zu deaktivieren oder um die gesamte Partitionierung für unpartitioned.example zu deaktivieren, würden Sie die Voreinstellung folgendermaßen setzen:

*,https://videos.example;unpartitioned.example,*