Zustandsaufteilung

Browser verknüpfen traditionell den client-seitigen Zustand mit dem Ursprung (oder manchmal der registrierbaren Domäne) der geladenen Ressource. 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, durch example.com verknüpft. Dies gilt unabhängig davon, ob der Browser derzeit Ressourcen von dieser Domäne als First-Party-Ressourcen lädt oder als eingebettete Drittanbieter-Ressourcen. Tracker haben diesen cross-site-Zustand genutzt, um Benutzeridentifikatoren zu speichern und auf sie über Websites hinweg zuzugreifen. Das folgende 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 Cookie-Richtlinien von Firefox versuchten, das Tracking zu mildern, indem sie für bestimmte Domänen unter bestimmten Bedingungen den Zugriff auf einige Speicher-APIs blockierten (z.B. Cookies und localStorage). Zum Beispiel verhindert unsere Politik "alle Drittanbieter-Cookies blockieren", dass alle Domänen auf bestimmte Speicher-APIs zugreifen, wenn sie in einem Drittanbieter-Kontext geladen werden. Unsere aktuelle Standard-Cookie-Richtlinie blockiert den Zugriff im Drittanbieter-Kontext nur für als Tracker klassifizierte Domänen.

Zustandsaufteilung ist ein anderer Ansatz zur Verhinderung von cross-site-Tracking. Anstatt den Zugriff auf bestimmte zustandsbehaftete APIs in einem Drittanbieter-Kontext zu blockieren, stellt Firefox eingebetteten Ressourcen einen separaten Speicherbereich für jede oberste Website zur Verfügung. Genauer gesagt, verknüpft Firefox den gesamten client-seitigen Zustand doppelt, basierend auf dem Ursprung der geladenen Ressource und der obersten Seite. In den meisten Fällen ist die oberste Seite das Schema und eTLD+1 der obersten Seite, die der Benutzer besucht.

Im folgenden Beispiel ist example.com in A.example und B.example eingebettet. Da Speicher jedoch partitioniert ist, gibt es drei unterschiedliche Speicherbereiche (anstatt einer). Der Tracker kann weiterhin auf den Speicher zugreifen, aber da jeder Speicherbereich zusätzlich unter der obersten Seite verknüpft ist, werden die Daten, auf die auf A zugegriffen werden kann, unterschiedlich sein von denen auf B. Dies wird verhindern, dass ein Tracker einen Identifikator in seinen Cookies speichert, wenn er direkt besucht wird, und diesen Identifikator dann abruft, wenn er in andere Websites eingebettet wird.

Die Privacy Community Group hat einen Arbeitsauftrag für Client-seitige Speicheraufteilung. Dies dient als Überblick über die Standardisierungsanstrengungen für die Speicheraufteilung in den betroffenen individuellen Standards. Wir beabsichtigen, unsere Implementierung der Zustandsaufteilung im Einklang mit diesen Bestrebungen zu bringen, sobald der Arbeitsauftrag standardisiert ist.

• Netzwerkaufteilung: Für alle Benutzer seit Firefox 85 standardmäßig aktiviert.
• Dynamische Aufteilung: Für alle Benutzer seit Firefox 103 standardmäßig aktiviert. Vorher:
  • Seit Firefox 86: Aktiviert für Benutzer, die "Strikte" Datenschutzmaßnahmen aktiviert haben.
  • Seit Firefox 90: Im privaten Modus aktiviert.

Um zu verhindern, dass über JavaScript zugängliche Speicher-APIs für cross-site tracking genutzt werden, wird zugänglicher Speicher nach oberster Seite partitioniert. Dieser Mechanismus bedeutet, dass ein Drittanbieter, der in einer obersten Seite eingebettet ist, grundsätzlich nicht auf Daten zugreifen kann, die unter einer anderen obersten Seite 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 werden die folgenden Netzwerk-APIs und Caches dauerhaft nach der obersten Seite partitioniert.

• HTTP Cache
• Bild-Cache
• Favicon-Cache
• Verbindungs-Pooling
• Stylesheet-Cache
• DNS
• HTTP-Authentifizierung
• Alt-Svc
• Spekulative Verbindungen
• Schriftarten & Schriftarten-Cache
• HSTS
• OCSP
• Intermediate CA Cache
• TLS-Client-Zertifikate
• TLS-Sitzungskennungen
• Prefetch
• Preconnect
• CORS-preflight Cache
• WebRTC deviceID
• Vorwärts/Rückwärts-Cache (bfcache)

Im Allgemeinen, wenn zugänglicher Speicher nach der obersten Seite partitioniert ist, kann trotzdem der Zugriff auf unpartitionierte Cookies von Dritten gewährt werden, wenn die Storage Access API unterstützt wird:

• mit der Storage Access API.
• automatisch, wie bei Dritten, die föderierte Anmeldungen bereitstellen.

Details zu automatischen Gewährungen werden im Abschnitt Storage Access Heuristics bereitgestellt.

• Cookies

Um die Web-Kompatibilität zu verbessern, enthält Firefox derzeit einige Heuristiken, um unpartitionierten Zugang zu Cookies von Dritten automatisch zu gewähren, die Benutzerinteraktionen empfangen. Diese Heuristiken sind dazu gedacht, zu ermöglichen, dass einige häufig auf dem Web vorkommende Drittanbieter-Integrationen weiterhin funktionieren.

Opener-Heuristik

Wenn ein partitionierter Drittanbieter ein Pop-up-Fenster öffnet, das opener-Zugriff auf das ursprüngliche Dokument hat und der Benutzer mit diesem Pop-up interagiert, wird dem Drittanbieter der Speicherzugriff für 30 Tage gewährt.

Navigationsheuristik

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

Drittanbieter-Frames können document.requestStorageAccess nutzen, um über die Storage Access API unpartitionierten Zugang zu Cookies anzufordern. Einmal gewährt, erhält die anfragende Partei Zugriff auf ihre gesamten First-Party-Cookies (d.h. die Cookies, auf die sie Zugriff hätte, wenn sie als First-Party besucht würde).

Wir empfehlen den Site-Betreibern, ihre Sites zu testen, insbesondere solche, die sich auf Integrationen von Drittanbieter-Inhalten verlassen. 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 Speichern in einem Drittanbieter-Kontext interagiert wird. In den folgenden Beispielen ist a.example die oberste Seite, die das Drittanbieter-Frame b.example einbettet.

Wenn ein Drittanbieter-iframe den Speicherzugriff auf den übergeordneten Kontext gewährt wird, setzt Firefox eine Berechtigung. Um den Zugriff aufzuheben, können Sie die Berechtigung über das Site-Informationsfenster im Berechtigungsbereich unter "Cross-site Cookies" löschen.

Web-Kompatibilitätsfunktionen deaktivieren

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

Von der Voreinstellung ausgeschlossene Funktionen umfassen:

• Speicherzugriffsheuristiken: Unpartitionierter Zugang zu Cookies kann nur über die Storage Access API erworben werden.
• Automatische Speicherzugriffsgewährungen: document.requestStorageAccess wird den Benutzer immer auffordern.
• SmartBlock's "unblock on opt-in" Funktion, die es bestimmten Trackern erlaubt, wenn Benutzer mit ihnen interagieren.
• Jegliche temporäre Anti-Tracking-Ausnahmen die Websites über den Skip-Listing-Mechanismus gewährt wurden.

Heuristiken deaktivieren

Die folgenden Voreinstellungen können verwendet werden, um einzelne Speicherzugriffsheuristiken über den Konfigurationseditor zu deaktivieren:

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

Netzwerkaufteilung deaktivieren

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

Dynamische Zustandsaufteilung deaktivieren

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

Bestimmte Ursprünge von der Aufteilung ausnehmen

Die dynamische Zustandsaufteilung kann auch für bestimmte Ursprünge mit der Voreinstellung privacy.restrict3rdpartystorage.skip_list deaktiviert werden. Diese Voreinstellung enthält eine durch Komma getrennte Liste von Ursprüngen, die ausgenommen werden sollen. Der Wert der Voreinstellung sollte das folgende Format verwenden: first-party_origin_1,third-party_origin_1;first-party_origin_2,third-party_origin_2;....

Zum Beispiel, um die Aufteilung für tracker.example auf example.com oder social.example auf news.example zu deaktivieren, würden Sie die Voreinstellung 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 für die Drittpartei verwenden. Zum Beispiel, um die Aufteilung für videos.example auf allen Seiten zu deaktivieren, oder um die gesamte Aufteilung auf unpartitioned.example zu deaktivieren, würden Sie die Voreinstellung wie folgt setzen:

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