State Partitioning

Motivation

Cross-Site-Tracking mit gemeinsam genutztem Zustand

Browser verwenden traditionell Schlüssel für clientseitige Zustände basierend auf dem Ursprung (oder manchmal auf der registrierbaren Domain), von der die Ressource geladen wurde. Zum Beispiel werden die Cookies, localStorage-Objekte und Caches, die einem Iframe zur Verfügung stehen, der von https://example.com/hello.html geladen wird, durch example.com gekennzeichnet. Dies gilt unabhängig davon, ob der Browser derzeit Ressourcen von dieser Domain als First-Party-Ressourcen oder als eingebettete Third-Party-Ressourcen lädt. Tracker haben diesen Cross-Site-Zustand genutzt, um Benutzerkennungen zu speichern und auf sie über verschiedene Websites hinweg zuzugreifen. Das untenstehende Beispiel zeigt, wie example.com seinen Cross-Site-Zustand (in diesem Fall Cookies) nutzen kann, um einen Benutzer sowohl auf seiner eigenen Website als auch auf A.example und B.example zu verfolgen.

Frühere Ansätze zur Blockierung von Cross-Site-Tracking

Die bisherigen Cookie-Richtlinien von Firefox versuchen, das Tracking zu mindern, indem sie den Zugriff auf bestimmte Speicher-APIs (z. B. Cookies und localStorage) für bestimmte Domains unter bestimmten Bedingungen blockieren. Zum Beispiel verhindert unsere Richtlinie "blockiere alle Third-Party-Cookies", dass alle Domains auf bestimmte Speicher-APIs zugreifen können, wenn sie in einem Third-Party-Kontext geladen werden. Unsere aktuelle Standard-Cookie-Richtlinie blockiert den Zugriff in einem Third-Party-Kontext nur für Domains, die als Tracker klassifiziert sind.

Zustandspartitionierung

Zustandspartitionierung ist ein anderer Ansatz, um Cross-Site-Tracking zu verhindern. Anstatt den Zugriff auf bestimmte zustandsbehaftete APIs in einem Third-Party-Kontext zu blockieren, stellt Firefox eingebetteten Ressourcen einen separaten Speichercontainer für jede Hauptwebsite zur Verfügung. Genauer gesagt, Firefox doppelt die Schlüssel für alle clientseitigen Zustände nach dem Ursprung der geladenen Ressource und der übergeordneten Website. In den meisten Fällen ist die übergeordnete Website das Schema und eTLD+1 der top-level Seite, die der Benutzer besucht.

Im untenstehenden Beispiel wird example.com in A.example und B.example eingebettet. Da der Speicher jedoch partitioniert ist, gibt es drei unterschiedliche Speichercontainer (anstatt nur einen). Der Tracker kann weiterhin auf den Speicher zugreifen, aber da jeder Speichercontainer zusätzlich unter der übergeordneten Website gekennzeichnet ist, unterscheiden sich die Daten, auf die er auf A zugreifen kann, von den Daten auf B. Dies verhindert, dass ein Tracker eine Kennung in seinen Cookies speichert, wenn er direkt besucht wird, und diese Kennung dann abruft, wenn er in andere Websites eingebettet ist.

Standardisierung

Die Privacy Community Group hat ein Arbeitselement für Client-Side Storage Partitioning. Dies dient als Übersicht über die Standardisierungsbemühungen für Speicherpartitionierung in den betroffenen Standards. Wir beabsichtigen, unsere Implementierung der Zustandspartitionierung mit diesen Bemühungen in Einklang zu bringen, wenn das Arbeitselement standardisiert wird.

Status der Partitionierung in Firefox

• 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: Aktiviert für Benutzer, die "Strikte" Datenschutzmaßnahmen aktiviert haben.
  • Seit Firefox 90: Aktiviert im privaten Modus.

Statische Partitionierung

Speicherpartitionierung

Um zu verhindern, dass über JavaScript zugängliche Speicher-APIs für das Cross-Site-Tracking genutzt werden, wird zugänglicher Speicher nach der übergeordneten Website partitioniert. Dieser Mechanismus bedeutet generell, dass eine Third-Party, die in eine übergeordnete Website eingebettet ist, nicht auf Daten zugreifen kann, die unter einer anderen übergeordneten Website gespeichert sind.

Speicher-APIs

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

Netzwerkpartitionierung

Netzwerkbezogene APIs sind nicht dazu gedacht, dass Websites Daten speichern, aber sie können missbraucht werden, um Cross-Site-Tracking zu betreiben. Daher sind die folgenden Netzwerk-APIs und Caches dauerhaft nach der übergeordneten Website partitioniert.

Netzwerk-APIs

• HTTP Cache
• Bild-Cache
• Favicon-Cache
• Verbindungs-Pooling
• Stylesheet-Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftarten-Cache
• HSTS
• OCSP
• Zwischen-CA-Cache
• TLS-Client-Zertifikate
• TLS-Sitzungs-Identifikatoren
• Prefetch
• Preconnect
• CORS-Preflight Cache
• WebRTC deviceID
• Backward/forward cache (bfcache)

Dynamische Partitionierung

Generell kann der Zugang zu nicht partitionierten Cookies von Third-Parties weiterhin gewährt werden, wenn die Storage Access API unterstützt wird:

• unter Verwendung der Storage Access API.
• automatisch, z. B. bei Third-Parties, die eine föderierte Anmeldung bereitstellen.

Details zu automatischen Genehmigungen finden Sie im Abschnitt Heuristiken für den Speicherzugang.

Dynamisch partitionierte APIs

• Cookies

Heuristiken für den Speicherzugang

Um die Webkompatibilität zu verbessern, enthält Firefox derzeit einige Heuristiken, um unpartitionierten Zugang zu Cookies automatisch für Third-Parties zu gewähren, die eine Benutzerinteraktion erhalten. Diese Heuristiken sollen es ermöglichen, dass einige Third-Party-Integrationen, die im Web üblich sind, weiterhin funktionieren.

Opener-Heuristik

Wenn ein partitionierter Third-Party eine Pop-up-Fenster öffnet, das Opener-Zugriff auf das ursprüngliche Dokument hat und der Benutzer mit diesem Pop-up interagiert, wird der Third-Party ein Speicherzugang für seinen Einbettungskontext für 30 Tage gewährt.

Navigations-Heuristik

Angenommen, eine Website unter a.example navigiert einen Benutzer zu b.example im selben Fenster, der Benutzer interagiert mit b.example, und dann wird der Benutzer schnell zurück zu a.example navigiert. In einem solchen Fall wird b.example als Third-Party auf a.example ein Speicherzugang für 30 Tage gewährt.

Storage Access API

Third-Party-Frames können document.requestStorageAccess verwenden, um unpartitionierten Zugang zu Cookie über die Storage Access API zu beantragen. Sobald der Zugang gewährt wird, erhält die anfragende Partei Zugang zu ihren gesamten First-Party-Cookies (d.h. zu den Cookies, auf die sie auch dann Zugriff hätte, wenn sie als First-Party besucht würde).

Debugging

Wir ermutigen Website-Besitzer, ihre Websites zu testen, insbesondere solche, die auf Integrationen mit Drittanbietern angewiesen sind. Es gibt mehrere Funktionen in Firefox, die das Testen erleichtern.

Protokollierung

Hier ist ein Überblick über die Nachrichten, die in die Webkonsole protokolliert werden, wenn im Third-Party-Kontext mit dem Speicher interagiert wird. In den folgenden Beispielen ist a.example die übergeordnete Website, die das Third-Party-Frame b.example einbettet.

Dritten Speicherzugang löschen

Wenn ein Third-Party-Iframe Speicherzugang zum übergeordneten Kontext gewährt wird, setzt Firefox eine Berechtigung. Um den Zugriff zu widerrufen, können Sie die Berechtigung über das Website-Informationsfenster im Berechtigungsbereich unter "Cross-site-Cookies" löschen.

Testeinstellungen

Webkompatibilitätsfunktionen deaktivieren

Das Setzen von privacy.antitracking.enableWebcompat auf false wird alle ETP- und Webkompatibilitätsfunktionen der Zustandspartitionierung 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.

Funktionen, die durch die Einstellung deaktiviert werden, umfassen:

• Heuristiken für den Speicherzugang: Unpartitionierter Zugang zu Cookies kann nur über die Storage Access API erworben werden.
• Automatische Speicherzugriffsberechtigungen: document.requestStorageAccess wird den Benutzer immer auffordern.
• SmartBlock's "Entsperren bei Opt-In"-Funktion, die bestimmte Tracker ermöglicht, wenn Benutzer mit ihnen interagieren.
• Jegliche temporären Anti-Tracking-Ausnahmen, die Websites durch den Skip-Listing-Mechanismus gewährt werden.

Heuristiken deaktivieren

Die folgenden Einstellungen können verwendet werden, um einzelne Heuristiken für den Speicherzugang über den Konfigurationseditor zu deaktivieren:

• Aktivieren / Deaktivieren der Navigations-Heuristik: privacy.restrict3rdpartystorage.heuristic.navigation
• Aktivieren / Deaktivieren der Opener-Heuristik: 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 Websites zu deaktivieren, können Sie die Einstellung network.cookie.cookieBehavior verwenden:

Andere Werte dieser Einstellung können den Zugriff auf Drittanbieterspeicher vollständig deaktivieren.

Spezifische 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 hält eine durch Kommas getrennte Liste von Ursprüngen, die ausgenommen werden sollen. Der Einstellungswert sollte folgendem Format folgen: 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 wie folgt setzen:

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

Sie können * als Platzhalter sowohl für die First- als auch die Third-Party verwenden. Zum Beispiel, um die Partitionierung für videos.example auf allen Seiten zu deaktivieren oder um alle Partitionierungen auf unpartitioned.example zu deaktivieren, würden Sie die Einstellung wie folgt setzen:

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