Partitionierung von Zuständen

Motivation

Cross-Site-Tracking mit gemeinsam genutztem Zustand

Browser verwenden traditionell den Ursprung (oder manchmal die registrierbare Domain) der Quelle, von der aus ein Ressource geladen wurde, um den clientseitigen Zustand festzulegen. Beispielsweise werden die Cookies, die localStorage-Objekte und Caches, die einem iframe, geladen von https://example.com/hello.html, zur Verfügung stehen, durch example.com festgelegt. 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 über Websites hinweg darauf zuzugreifen. Das untenstehende Beispiel zeigt, wie example.com seinen Cross-Site-Zustand (in diesem Fall Cookies) verwenden kann, um einen Benutzer sowohl auf seiner eigenen Website als auch auf A.example und B.example zu verfolgen.

Bisherige Ansätze zur Blockierung von Cross-Site-Tracking

Firefoxx's bisherige Cookie-Richtlinien 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. Beispielsweise verhindert unsere „Blockieren Sie alle Drittanbieter-Cookies“-Richtlinie, dass alle Domains auf bestimmte Speicher-APIs zugreifen, wenn sie im Drittanbieter-Kontext geladen werden. Unsere aktuelle standardmäßige Cookie-Richtlinie blockiert den Zugriff im Drittanbieter-Kontext nur für Domains, die als Tracker klassifiziert sind.

Partitionierung von Zuständen

Die Partitionierung von Zuständen ist ein anderer Ansatz, um Cross-Site-Tracking zu verhindern. Anstatt den Zugriff auf bestimmte zustandsbezogene APIs im Drittanbieter-Kontext zu blockieren, bietet Firefox eingebetteten Ressourcen ein separates Speicherverzeichnis für jede Top-Level-Website. Genauer gesagt, Firefox doppelschlüsselt alle clientseitigen Zustände nach dem Ursprung der geladenen Ressource und der Top-Level-Site. In den meisten Fällen ist die Top-Level-Site das Schema und die registrierbare Domain der von dem Benutzer besuchten Top-Level-Seite.

Im untenstehenden Beispiel ist example.com in A.example und B.example eingebettet. Da der Speicher jedoch partitioniert ist, gibt es drei getrennte Speicherverzeichnisse (statt eines). Der Tracker kann weiterhin auf den Speicher zugreifen, aber da jedes Speicherverzeichnis zusätzlich unter der Top-Level-Site verschlüsselt ist, werden die Daten, auf die es bei A zugreifen kann, anders sein als die bei B. Dies verhindert, dass ein Tracker eine Kennung in seinen Cookies speichert, wenn er direkt besucht wird, und diese Kennung dann beim Einbetten in andere Websites abruft.

Standardisierung

Die Privacy Community Group hat ein Arbeitselement für Client-Seitige Speicherpartitionierung. Dies dient als Übersicht über die Standardisierungsbemühungen für Speicherpartitionierung in den betroffenen individuellen Standards. Wir beabsichtigen, unsere Implementierung der Partitionierung von Zuständen mit diesen Bemühungen in Einklang zu bringen, während das Arbeitselement standardisiert wird.

Status der Partitionierung in Firefox

• Netzwerkpartitionierung: Seit Firefox 85 standardmäßig für alle Nutzer aktiviert.
• Dynamische Partitionierung: Seit Firefox 103 standardmäßig für alle Nutzer aktiviert. Davor:
  • Seit Firefox 86: Aktiviert für Nutzer, die "Strenge" Datenschutzeinstellungen aktiviert haben.
  • Seit Firefox 90: Aktiviert im privaten Modus.

Statische Partitionierung

Speicherpartitionierung

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

Speicher-APIs

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

Netzwerkpartitionierung

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

Netzwerk-APIs

• HTTP Cache
• Image Cache
• Favicon Cache
• Connection Pooling
• Script Cache
• Stylesheet Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftart-Cache
• HSTS
• OCSP
• Cache für Zwischenzertifizierungsstellen (CA)
• TLS-Client-Zertifikate
• TLS-Sitzungskennungen
• Prefetch
• Vorverbindung
• CORS-Preflight Cache
• WebRTC deviceID
• Vorwärts-/Rückwärtscache (bfcache)

Dynamische Partitionierung

Im Allgemeinen gilt, dass wenn zugänglicher Speicher nach Top-Level-Site partitioniert ist, der Zugang zu unpartitionierten Cookies Dritter immer noch gewährt werden kann, wenn die Storage Access API unterstützt wird:

• durch die Verwendung der Storage Access API.
• automatisch, zum Beispiel für Drittanbieter, die eine föderierte Anmeldung bereitstellen.

Details zu automatischen Gewährungen finden Sie im Abschnitt Heuristiken für den Speicherzugang.

Dynamisch partitionierte APIs

• Cookies

Heuristiken für den Speicherzugang

Um die Web-Kompatibilität zu verbessern, enthält Firefox derzeit einige Heuristiken, die unpartitionierbaren Zugriff auf Cookies automatisch für Dritte gewähren, wenn diese eine Benutzerinteraktion erhalten. Diese Heuristiken sollen ermöglichen, dass einige auf dem Web häufig vorkommende Drittanbieter-Integrationen weiterhin funktionieren.

Heuristik für den Opener

Wenn ein partitionierter Drittanbieter ein Popup-Fenster öffnet, das Opener-Zugriff auf das Ursprungsdokument hat und der Benutzer mit diesem Popup interagiert, wird dem Drittanbieter der Speicherzugang zu seinem Einbettungskontext für 30 Tage gewährt.

Heuristik für die Navigation

Angenommen, eine Website, die auf a.example gehostet wird, leitet einen Benutzer zu b.example im selben Fenster weiter, der Benutzer interagiert mit b.example und dann wird der Benutzer schnell zu a.example zurücknavigiert. In einem solchen Fall wird b.example Speicherzugang als Drittanbieter auf a.example für 30 Tage gewährt.

Storage Access API

Drittanbieter-Frames können document.requestStorageAccess verwenden, um unpartitionierten Zugriff auf Cookies durch die Storage Access API zu beantragen. Sobald dieser gewährt wird, erhält die antragstellende 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).

Debugging

Wir ermutigen Website-Besitzer, ihre Seiten zu testen, insbesondere diejenigen, die auf Integrationen mit Drittanbieter-Inhalten angewiesen sind. In Firefox gibt es mehrere Funktionen, die das Testen erleichtern.

Protokollierung

Hier ist ein Überblick über die Nachrichten, die bei der Interaktion mit Speicher in einem Drittanbieter-Kontext in der Web-Konsole protokolliert werden. In den folgenden Beispielen ist a.example die Top-Level-Site, die das Drittanbieter-Frame b.example einbettet.

Löschen des Drittanbieterspeicherzugangs

Wenn einem Drittanbieter-iframe Speicherzugang zum übergeordneten Kontext gewährt wird, setzt Firefox eine Berechtigung. Um den Zugang zu widerrufen, können Sie die Berechtigung über das Site-Informations-Panel im Berechtigungsabschnitt unter „Cross-site Cookies“ löschen.

Testeinstellungen

Deaktivieren von Web-Kompatibilitätsfunktionen

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 nicht von temporären Heuristiken abhängt.

Zu den durch den pref deaktivierten Funktionen gehören:

• Speicherzugangs-Heuristiken: Unpartitionierter Zugriff auf Cookies kann nur über die Storage Access API erlangt werden.
• Automatische Speicherzugangsverleihungen: document.requestStorageAccess wird immer den Benutzer auffordern.
• SmartBlock's "unblock on opt-in" Feature, das bestimmte Tracker erlaubt, wenn Benutzer mit ihnen interagieren.
• Alle temporären Anti-Tracking-Ausnahmen, die Webseiten über den Skip-Listing-Mechanismus gewährt werden.

Deaktivieren von Heuristiken

Die folgenden Einstellungen können verwendet werden, um einzelne Speicherzugangs-Heuristiken über den config editor zu deaktivieren:

• Aktivieren / Deaktivieren der Navigationsheuristik: privacy.restrict3rdpartystorage.heuristic.navigation
• Aktivieren / Deaktivieren der Opener-Heuristik: privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction

Deaktivieren der Netzwerkpartitionierung

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

Deaktivieren der dynamischen Zustandspartitionierung

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

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

Ausnahmen für bestimmte Ursprünge von der Partitionierung

Die dynamische Zustandspartitionierung kann auch für bestimmte Ursprünge mit der Einstellung privacy.restrict3rdpartystorage.skip_list deaktiviert werden. Diese Einstellung enthält eine kommagetrennte Liste von Ursprüngen, die ausgenommen sind. Der Einstellungswert sollte das folgende Format befolgen: 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 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 First- oder 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 auf Folgendes setzen:

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