Partitionierung des Zustands

Browser verwenden traditionell den Ursprung (oder manchmal die registrierbare Domain) des Ortes, von dem ein Ressourcen geladen wurde, um den clientseitigen Zustand zu kennzeichnen. Beispielweise werden die Cookies, localStorage-Objekte und Caches, die einem iframe zur Verfügung stehen, das von https://example.com/hello.html geladen wird, nach example.com gekennzeichnet. Dies gilt unabhängig davon, ob der Browser derzeit Ressourcen von dieser Domain als Erstanbieter oder als eingebettete Drittanbieter-Ressourcen lädt. Tracking-Anbieter haben diesen cross-site Zustand genutzt, um Benutzeridentifikatoren zu speichern und diese über Websites hinweg abzurufen. Das folgende Beispiel zeigt, wie example.com seinen interaktiven Zustand (in diesem Fall Cookies) verwenden kann, um einen Benutzer sowohl auf seiner eigenen Site als auch auf A.example und B.example zu verfolgen.

Frühere Cookie-Richtlinien von Firefox versuchten, Tracking zu mindern, indem der Zugriff auf einige Speicher-APIs (z. B. Cookies und localStorage) für bestimmte Domains unter bestimmten Bedingungen blockiert wurde. Beispielsweise verhindert unsere "Blockiere alle Drittanbieter-Cookies"-Richtlinie, dass alle Domains, wenn sie in einem Drittanbieter-Kontext geladen werden, auf bestimmte Speicher-APIs zugreifen können. Unsere aktuelle Standard-Cookie-Richtlinie blockiert den Zugriff im Drittanbieter-Kontext nur für als Tracker klassifizierte Domains.

Die Partitionierung des Zustands ist ein anderer Ansatz zur Vermeidung von Cross-Site-Tracking. Anstatt den Zugriff auf bestimmte zustandsbehaftete APIs im Drittanbieter-Kontext zu blockieren, stellt Firefox eingebetteten Ressourcen einen separaten Speicherbereich für jede Top-Level-Website zur Verfügung. Konkret schlüsselt Firefox den gesamten clientseitigen Zustand doppelt nach dem Ursprung der ladenden Ressource und der Top-Level-Website. In den meisten Fällen ist die Top-Level-Website das Schema und eTLD+1 der Top-Level-Seite, die der Benutzer besucht.

Im folgenden Beispiel wird example.com in A.example und B.example eingebettet. Da der Speicher jedoch partitioniert ist, gibt es drei unterschiedliche Speicherbereiche (statt eines). Der Tracker kann zwar noch auf Speicher zugreifen, aber da jeder Speicherbereich zusätzlich unter der Top-Level-Website gekennzeichnet ist, werden die Daten, auf die er Zugriff hat, auf A anders sein als auf B. Dies verhindert, dass ein Tracker einen Identifikator in seinen Cookies speichert, wenn er direkt besucht wird, und dann diesen Identifikator abrufen kann, wenn er in anderen Websites eingebettet ist.

Die Privacy Community Group hat ein Arbeitsitem für die Client-Side Storage Partitioning. Dies dient als Übersicht über die Standardisierungsbemühungen für die Speicherpartitionierung in den betroffenen individuellen Standards. Wir beabsichtigen, unsere Implementierung der Zustands-Partitionierung mit diesen Bemühungen abzustimmen, sobald das Arbeitsitem standardisiert ist.

• Netzwerk-Partitionierung: 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: Aktiviert für Benutzer, die „strenge“ Datenschutzschutzeinstellungen aktivieren.
  • Seit Firefox 90: Aktiviert im privaten Modus.

Um zu verhindern, dass JavaScript-zugängliche Speicher-APIs für Cross-Site-Tracking verwendet werden, wird der zugängliche Speicher nach der Top-Level-Site partitioniert. Dieser Mechanismus bedeutet im Allgemeinen, dass ein Drittanbieter, der in eine Top-Level-Site eingebettet ist, nicht auf Daten zugreifen kann, die unter einer anderen Top-Level-Site gespeichert sind.

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

Netzwerkbezogene APIs sind nicht dazu gedacht, von Websites zum Speichern von Daten verwendet zu werden, aber sie können für Cross-Site-Tracking missbraucht werden. Daher sind die folgenden Netzwerk-APIs und Caches dauerhaft nach der Top-Level-Site partitioniert.

• HTTP-Cache
• Bild-Cache
• Favicon-Cache
• Verbindungspooling
• Stylesheet-Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftarten-Cache
• HSTS
• OCSP
• Zwischenzertifizierungsstellen-Cache
• TLS-Client-Zertifikate
• TLS-Sitzungskennungen
• Prefetch
• Preconnect
• CORS-Preflight Cache
• WebRTC deviceID

Wenn im Allgemeinen zugänglicher Speicher nach Top-Level-Site partitioniert ist, kann der Zugriff auf nicht partitionierte Cookies von Drittanbietern noch gewährt werden, wenn die Speicherzugriffs-API unterstützt wird:

• durch Nutzung der Storage Access API.
• automatisch, z. B. für Drittanbieter, die eine föderierte Anmeldung bereitstellen.

Details zu automatischen Gewährungen finden sich im Abschnitt Storage Access Heuristics.

• Cookies

Um die Kompatibilität mit dem Web zu verbessern, enthält Firefox derzeit einige Heuristiken, um Drittanbietern, die Benutzerinteraktionen erhalten, automatisch unpartitionierten Zugriff auf Cookies zu gewähren. Diese Heuristiken sollen es ermöglichen, dass einige Drittanbieter-Integrationen, die im Web üblich sind, weiterhin funktionieren.

Opener-Heuristiken

• Wenn ein partitionierter Drittanbieter ein Pop-up-Fenster öffnet, das opener access zu dem Ausgangsdokument hat, erhält der Drittanbieter Speicherzugriff auf seinen Einbettungsanbieter für 30 Tage.
• Wenn ein Erstanbieter a.example ein Drittanbieter-Pop-up b.example öffnet, erhält b.example für 30 Tage Drittanbieter-Speicherzugriff auf a.example.

Weiterleitungsheuristik

• Wenn eine Site b.example zu a.example umleitet, erhält b.example Speicherzugriff auf seinen Einbettungsanbieter a.example, wenn sowohl a.example als auch b.example innerhalb der letzten 10 Minuten besucht und mit ihnen interagiert wurde. Dieser Speicherzugriff wird für 15 Minuten gewährt.
• Wenn ein Tracker tracker.example (wie durch den Enhanced Tracking Protection klassifiziert) zu einem Nicht-Tracker a.example umleitet und tracker.example in den letzten 45 Tagen als Erstanbieter Benutzerinteraktionen erhalten hat, erhält tracker.example Speicherzugriff auf a.example für 15 Minuten.

Drittanbieter-Frames können document.requestStorageAccess verwenden, um über die Storage Access API unpartitionierten Zugriff auf Cookies zu beantragen. Sobald dies gewährt wird, wird der anfragende Drittanbieter Zugriff auf seine gesamten Erstanbieter-Cookies erhalten (d. h. die Cookies, auf die er Zugriff hätte, wenn er als Erstanbieter besucht wird).

Wir ermutigen Website-Betreiber, ihre Sites zu testen, insbesondere diejenigen, die sich auf Integrationen von Drittanbietern stützen. Es gibt mehrere Funktionen in Firefox, um das Testen zu erleichtern.

Hier ist ein Überblick über die Nachrichten, die an die Webkonsole protokolliert werden, wenn im Drittanbieter-Kontext mit Speicher interagiert wird. In den folgenden Beispielen ist a.example die Top-Level-Site, die das Drittanbieter-Frame b.example einbettet.

Wird einem Drittanbieter-iframe Speicherzugriff auf den übergeordneten Kontext gewährt, setzt Firefox eine Berechtigung. Um den Zugriff zu widerrufen, können Sie die Berechtigung über das Site-Informationsfeld im Abschnitt Berechtigungen unter "Cross-site Cookies" löschen.

Webkompatibilitätsfunktionen deaktivieren

Das Setzen von privacy.antitracking.enableWebcompat auf false wird alle Webkompatibilitätsmerkmale von ETP und der Zustandspartitionierung deaktivieren. Das Deaktivieren dieser Merkmale kann beim Testen nützlich sein, um sicherzustellen, dass Ihre Website vollständig mit dem Mechanismus der Zustandspartitionierung in Firefox kompatibel ist und sich nicht auf temporäre Heuristiken verlässt.

Die durch die Einstellung deaktivierten Funktionen umfassen:

• Speicherzugangsheuristik: Unpartitionierter Zugriff auf Cookies kann nur über die Storage Access API erworben werden.
• Automatische Speicherzugriffsgenehmigungen: document.requestStorageAccess wird immer den Benutzer auffordern.
• SmartBlock's "unblock on opt-in" feature, das bestimmten Trackern erlaubt, wenn Benutzer mit ihnen interagieren.
• Alle temporären Anti-Tracking-Ausnahmen, die Websites über den Skip-Listing-Mechanismus gewährt werden.

Heuristiken deaktivieren

Die folgenden Präferenzen können verwendet werden, um individuelle Speicherzugangsheuristiken über den Konfigurationseditor zu deaktivieren:

• Aktivieren / deaktivieren der Weiterleitungsheuristiken: privacy.restrict3rdpartystorage.heuristic.recently_visited, privacy.restrict3rdpartystorage.heuristic.redirect
• Aktivieren / deaktivieren der Fenster-öffnen Heuristik: privacy.restrict3rdpartystorage.heuristic.window_open, privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction

Netzwerk-Partitionierung deaktivieren

Die Netzwerk-Partitionierung kann mit der privacy.partition.network_state Pref deaktiviert werden.

Dynamische Zustandspartitionierung deaktivieren

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

Bestimmte Ursprünge von der Partitionierung ausnehmen

Die dynamische Zustandspartitionierung kann auch für bestimmte Ursprünge mit der privacy.restrict3rdpartystorage.skip_list Präferenz deaktiviert werden. Diese Präferenz hält eine durch Kommas getrennte Liste von Ursprüngen, die ausgenommen werden sollen. Der Präferenzwert 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 Präferenz auf folgendes setzen:

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

Sie können * als Joker für entweder den ersten oder dritten Anbieter verwenden. Zum Beispiel, um die Partitionierung für videos.example auf allen Sites zu deaktivieren oder um alle Partitionierungen auf unpartitioned.example zu deaktivieren, würden Sie die Präferenz auf folgendes setzen:

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