Zustandspartitionierung

Browser ordnen traditionell den clientseitigen Zustand nach dem Origin (oder manchmal der registrierbaren Domain) der Quelle, von der eine Ressource geladen wurde. Zum Beispiel werden die Cookies, localStorage-Objekte und Caches, die einem in https://example.com/hello.html geladenen iframe zur Verfügung stehen, durch example.com gekennzeichnet. Dies gilt unabhängig davon, ob der Browser derzeit Ressourcen von dieser Domain als First-Party Ressourcen lädt oder als eingebettete Third-Party Ressourcen. Tracker haben diesen Cross-Site-Zustand genutzt, um Benutzerkennungen zu speichern und auf diese über Websites hinweg zuzugreifen. Das folgende Beispiel zeigt, wie example.com seinen Cross-Site-Zustand (in diesem Fall Cookies) verwenden kann, um einen Benutzer über seine eigene Seite sowie A.example und B.example zu verfolgen.

Firefox' frühere Cookie-Richtlinien versuchen, das Tracking durch Blockierung des Zugriffs auf einige Speicher-APIs (z.B. Cookies und localStorage) für bestimmte Domains unter bestimmten Bedingungen zu verringern. Unsere "Blockiere alle Drittanbieter-Cookies"-Richtlinie verhindert beispielsweise, dass alle Domains auf bestimmte Speicher-APIs zugreifen können, wenn sie in einem Drittanbieter-Kontext geladen werden. Unsere aktuelle Standard-Cookie-Richtlinie blockiert den Zugriff im Drittanbieter-Kontext nur für Domains, die als Tracker klassifiziert sind.

Die Zustandspartitionierung ist ein anderer Ansatz zur Verhinderung von Cross-Site-Tracking. Anstatt den Zugriff auf bestimmte stateful APIs in einem Drittanbieter-Kontext zu blockieren, stellt Firefox eingebetteten Ressourcen einen separaten Speicherbereich für jede oberste Website bereit. Genauer gesagt, doppelt Firefox alle clientseitigen Zustände nach dem Origin der geladenen Ressource und der obersten Site. In den meisten Fällen ist die oberste Seite das Schema und eTLD+1 der von dem Benutzer besuchten obersten Seite.

Im folgenden Beispiel ist example.com in A.example und B.example eingebettet. Da der Speicher jedoch partitioniert ist, gibt es drei verschiedene Speicherbereiche (anstatt eines). Der Tracker kann weiterhin auf den Speicher zugreifen, aber da jeder Speicherbereich zusätzlich unter der obersten Site gekennzeichnet ist, sind die Daten, auf die es Zugriff auf A hat, anders als die Daten auf B. Dies wird verhindern, dass ein Tracker eine Kennung in seinen Cookies speichert, wenn er direkt besucht wird und diese Kennung abruft, wenn er in anderen Websites eingebettet ist.

Die Privacy Community Group hat ein Arbeitsobjekt für Client-Side Storage Partitioning. Dies dient als Überblick über die Standardisierungsbemühungen für die Speicherpartitionierung in den betroffenen Einzelstandards. Wir beabsichtigen, unsere Implementierung der Zustandspartitionierung mit diesen Bemühungen abzustimmen, während das Arbeitsobjekt standardisiert wird.

• Netzwerkpartitionierung: Seit Firefox 85 standardmäßig für alle Benutzer aktiviert.
• Dynamische Partitionierung: Seit Firefox 103 standardmäßig für alle Benutzer aktiviert. Vorher:
  • Seit Firefox 86: Für Benutzer aktiviert, die "Strenge" Datenschutzmaßnahmen aktiviert haben.
  • Seit Firefox 90: Im privaten Surfen aktiviert.

Um zu verhindern, dass von JavaScript zugängliche Speicher-APIs für Cross-Site-Tracking verwendet werden, wird der zugängliche Speicher nach der obersten Site partitioniert. Dieser Mechanismus bedeutet, dass ein Drittanbieter, der in einer obersten Site eingebettet ist, im Allgemeinen nicht auf Daten zugreifen kann, die unter einer anderen obersten Site 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 Cross-Site-Tracking missbraucht werden. Daher sind die folgenden Netzwerk-APIs und Caches dauerhaft nach der obersten Site partitioniert.

• HTTP Cache
• Bild-Cache
• Favicon-Cache
• Verbindungspool
• Stylesheet-Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftarten-Cache
• HSTS
• OCSP
• Zwischenzertifikatsstelle (CA)-Cache
• TLS-Client-Zertifikate
• TLS-Sitzungskennungen
• Vorausladen
• Vorverbinden
• CORS-preflight Cache
• WebRTC deviceID

Im Allgemeinen, wenn zugänglicher Speicher nach oberster Site partitioniert ist, kann der Zugriff auf unpartitionierte Cookies von Drittanbietern immer noch gewährt werden, wenn die Storage Access API unterstützt wird:

• Durch Verwendung der Storage Access API.
• Automatisch, z.B. für Drittanbieter, die eine föderierte Anmeldung bereitstellen.

Details zu automatischen Genehmigungen sind im Abschnitt Storage Access Heuristics enthalten.

• Cookies

Um die Webkompatibilität zu verbessern, enthält Firefox derzeit einige Heuristiken, um unpartitionierten Zugriff auf Cookies automatisch an Drittanbieter zu gewähren, die Benutzerinteraktionen erhalten. Diese Heuristiken sollen es einigen Drittanbieter-Integrationen, die im Web häufig vorkommen, ermöglichen, weiterhin zu funktionieren.

Öffner-Heuristiken

• Wenn ein partitionierter Drittanbieter ein Popup-Fenster öffnet, das öffner Zugriff auf das ursprüngliche Dokument hat, wird dem Drittanbieter der Speicherzugriff auf seine Einbettung für 30 Tage gewährt.
• Wenn eine First-Party a.example ein Drittanbieter-Popup b.example öffnet, wird b.example der Drittanbieter-Speicherzugriff auf a.example für 30 Tage gewährt.

Redirect-Heuristiken

• Wenn eine Seite b.example zu a.example weiterleitet, erhält b.example Speicherzugriff auf ihre Einbettung a.example, wenn sowohl a.example als auch b.example innerhalb der letzten 10 Minuten besucht und damit interagiert wurde. Dieser Speicherzugriff wird für 15 Minuten gewährt.
• Wenn ein Tracker tracker.example (wie durch den verbesserten Tracking-Schutz klassifiziert) zu einem Nicht-Tracker a.example weiterleitet und tracker.example als First-Party innerhalb der letzten 45 Tage Benutzerinteraktion erhalten hat, wird tracker.example Speicherzugriff auf a.example für 15 Minuten gewährt.

Drittanbieter-Frames können document.requestStorageAccess verwenden, um nicht partitionierten Zugriff auf Cookies durch die Storage Access API zu beantragen. Sobald der Zugriff gewährt wird, erhält die anfragende Partei Zugriff auf ihre gesamten First-Party-Cookies (d.h. die Cookies, auf die sie zugreifen könnte, wenn sie als First-Party besucht wird).

Wir ermutigen Seiteninhaber, ihre Seiten zu testen, insbesondere solche, die auf Integrationen von Drittanbieterinhalten angewiesen sind. Es gibt mehrere Funktionen in Firefox, die das Testen erleichtern.

Hier ist ein Überblick über die Nachrichten, die in der Webkonsole protokolliert werden, wenn mit Speicher in einem Drittanbieter-Kontext interagiert wird. In den folgenden Beispielen ist a.example die oberste Site, die den Drittanbieter-Frame b.example einbettet.

Wenn einem Drittanbieter-iframe der Speicherzugriff auf den übergeordneten Kontext gewährt wird, setzt Firefox eine Berechtigung. Um den Zugriff zu widerrufen, können Sie die Berechtigung über das Seiteninformationsfenster im Berechtigungsabschnitt unter "Cross-site Cookies" löschen.

Webkompatibilitätsfunktionen deaktivieren

Einstellung von privacy.antitracking.enableWebcompat auf false wird alle ETP- und Zustandspartitionierungswebkompatibilitätsfunktionen deaktivieren. Das Deaktivieren dieser Funktionen kann beim Testen nützlich sein, um sicherzustellen, dass Ihre Website vollständig mit dem Zustandspartitionierungsmechanismus in Firefox kompatibel ist und nicht auf temporäre Heuristiken angewiesen ist.

Von der Einstellung deaktivierte Funktionen umfassen:

• Speicherzugriffsheuristiken: Unpartitionierter Zugriff auf Cookies kann nur über die Storage Access API erworben werden.
• Automatische Speicherzugriffsgewährungen: document.requestStorageAccess wird den Benutzer immer auffordern.
• SmartBlock's "entsperren bei Zustimmung" Funktion, die bestimmte Tracker erlaubt, wenn Benutzer mit ihnen interagieren.
• Alle temporären Anti-Tracking-Ausnahmen, die Websites über den Skip-List-Mechanismus gewährt werden.

Heuristiken deaktivieren

Die folgenden Einstellungen können verwendet werden, um einzelne Speicherzugriffsheuristiken über den Konfigurations-Editor zu deaktivieren:

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

Netzwerkpartitionierung deaktivieren

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

Dynamische Zustandspartitionierung deaktivieren

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

Bestimmte Ursprünge von der Partitionierung ausnehmen

Die dynamische Zustandspartitionierung kann auch für bestimmte Ursprünge mit der Einstellung privacy.restrict3rdpartystorage.skip_list deaktiviert werden. Diese Einstellung enthält eine durch Kommas getrennte Liste von Ursprungen, die ausgenommen werden sollen. Der Einstellungswert sollte folgendes Format haben: first-party_origin_1,third-party_origin_1;first-party_origin_2,third-party_origin_2;....

Zum Beispiel, um die Partitionierung für tracker.example auf example.com oder social.example auf news.example zu deaktivieren, würden Sie die Einstellung auf folgendes setzen:

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

Sie können * als Platzhalter für entweder die erste oder die dritte Partei verwenden. Um z.B. die Partitionierung für videos.example auf allen Seiten zu deaktivieren, oder um die gesamte Partitionierung auf unpartitioned.example zu deaktivieren, würden Sie die Einstellung auf folgendes setzen:

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