Redirect Tracking Protection

Redirect-Tracking ist ein Missbrauch der plattformübergreifenden Navigation, bei dem ein Tracker den Benutzer vorübergehend zu seiner Website umleitet, um First-Party-Speicher zu nutzen, um diesen Benutzer über Websites hinweg zu verfolgen.

Plattformübergreifende Navigationen sind ein Kernmerkmal des Webs; jemand könnte zum Beispiel nach "beste Laufschuhe" in einer Suchmaschine suchen, ein Suchergebnis anklicken, um Bewertungen zu lesen, und letztendlich auf einen Link klicken, um ein Paar Schuhe in einem Online-Shop zu kaufen. Früher konnten jede dieser Websites Ressourcen desselben Trackers einbetten, und der Tracker konnte seine Cookies nutzen, um alle diese Seitenbesuche derselben Person zuzuordnen. Um die Privatsphäre ihrer Benutzer zu schützen, blockieren Browser Tracker daran, Cookies zu verwenden, wenn sie in einem Drittanbieter-Kontext eingebettet sind (siehe zum Beispiel Firefoxs Enhanced Tracking Protection (ETP)), erlauben jedoch weiterhin die Verwendung von Cookies als First-Party, da das Blockieren von First-Party-Cookies Websites zum Absturz bringen könnte. Redirect-Tracking nutzt dies aus, um die Blockierung von Drittanbieter-Cookies zu umgehen.

Redirect-Tracker funktionieren, indem sie einen unmerklichen und kurzen Zwischenstopp auf ihrer Website als Teil dieser Reise erzwingen. Anstatt also direkt von der Bewertungswebsite zum Einzelhändler zu navigieren, gelangen Sie zuerst über den Redirect-Tracker zum Einzelhändler. Das bedeutet, dass der Tracker als First-Party geladen wird. Der Redirect-Tracker verknüpft Tracking-Daten mit den Kennungen, die er in seinen First-Party-Cookies gespeichert hat, und leitet Sie dann zum Einzelhändler weiter.

Ein Ursprung wird gelöscht, wenn er die folgenden Bedingungen erfüllt:

1. Er hat innerhalb der letzten 72 Stunden Cookies gespeichert oder auf anderen Website-Speicher (z.B. localStorage, IndexedDB oder die Cache API) zugegriffen. Da Cookies pro Host sind, löschen wir sowohl die http- als auch die https-Ursprung-Varianten eines Cookie-Hosts.

2. Der Ursprung ist in unserer Tracking-Schutzliste als Tracker klassifiziert.

3. Kein Ursprung mit derselben Basisdomain (eTLD+1) hat eine Benutzerinteraktions-Erlaubnis.

   • Diese Erlaubnis wird einem Ursprung für 45 Tage gewährt, sobald ein Benutzer mit einem Top-Level-Dokument von diesem Ursprung interagiert. "Interagieren" umfasst das Scrollen.
   • Obwohl diese Erlaubnis auf einer per-Ursprung-Basis gespeichert wird, prüfen wir, ob ein beliebiger Ursprung mit derselben Basisdomain sie hat, um zu vermeiden, dass Sites mit Subdomains und entsprechender Cookie-Einstellung beschädigt werden.

Firefox löscht die folgenden Daten:

• Netzwerk-Cache und Bild-Cache
• Cookies
• AppCache
• DOM-Quota-Speicher (localStorage, IndexedDB, ServiceWorkers, DOM-Cache, etc.)
• DOM-Push-Benachrichtigungen
• Reporting API-Berichte
• Sicherheitseinstellungen (d.h. HSTS)
• EME-Media-Plugin-Daten
• Plug-in-Daten (z.B. Flash)
• Media-Geräte
• Speicherzugriffsberechtigungen, die dem Ursprung erteilt wurden
• HTTP-Authentifizierungs-Token
• HTTP-Authentifizierungs-Cache

Die Speicherlöschung ignoriert Ursprungsattribute. Das bedeutet, dass der Speicher über Container und isolierte Speicher (d.h. aus First-Party Isolation) hinweg gelöscht wird.

Firefox löscht den Speicher basierend auf dem Auslösen eines internen Ereignisses namens idle-daily, das durch die folgenden Bedingungen definiert ist:

• Es wird frühestens 24 Stunden nach dem letzten idle-daily-Ereignis ausgelöst.
• Es wird nur ausgelöst, wenn der Benutzer mindestens 3 Minuten (für 24-48 Stunden nach dem letzten idle-daily) oder 1 Minute (für >48 Stunden nach dem letzten idle-daily) inaktiv war.

Dies bedeutet, dass mindestens 24 Stunden zwischen jeder Speicherlöschung liegen und der Speicher nur gelöscht wird, wenn der Browser inaktiv ist. Beim Löschen von Cookies sortieren wir Cookies nach dem Erstellungsdatum und teilen sie aus Leistungsgründen in Sätze von 100 (gesteuert durch die Pref privacy.purge_trackers.max_purge_count).

Redirect-Tracking-Schutz kann aktiviert oder deaktiviert werden, indem Sie die Einstellung privacy.purge_trackers.enabled in about:config umschalten. Außerdem wird er nur ausgeführt, wenn die Pref network.cookie.cookieBehavior in Firefox 79+ auf 4 oder 5 gesetzt ist (1, 3, 4 oder 5 ab Firefox 80).

Unterschiedliche Protokollebene können über die Pref privacy.purge_trackers.logging.level festgelegt werden.

Zu Debugging-Zwecken ist es am einfachsten, die Speicherlöschung direkt über die Browserkonsole-Befehlszeile auszulösen. Beachten Sie, dass dies sich von der regulären Webkonsole unterscheidet, die Sie möglicherweise zur Fehlerbehebung einer Website verwenden, und erfordert, dass die Pref devtools.chrome.enabled auf true gesetzt ist, um sie interaktiv zu verwenden. Sobald Sie die Browserkonsole aktiviert haben, können Sie die Speicherlöschung durch Ausführen des folgenden Befehls auslösen:

await Components.classes["@mozilla.org/purge-tracker-service;1"]
  .getService(Components.interfaces.nsIPurgeTrackerService)
  .purgeTrackingCookieJars();

Die Zeit bis zum Ablauf der Benutzerinteraktionsberechtigungen kann mit der Pref privacy.userInteraction.expiration auf einen niedrigeren Wert gesetzt werden. Beachten Sie, dass Sie diese Pref festlegen müssen, bevor Sie die Websites besuchen, die Sie testen möchten — es wird nicht rückwirkend angewendet.

WebKit hat den Redirect-Tracking-Schutz erstmals in ITP 2.0 eingeführt (sie beziehen sich auf denselben Angriff als Bounce-Tracking). Ab Juli 2020 gibt es mehrere wesentliche Unterschiede zwischen der Implementierung von WebKit und der von Firefox:

• Die Liste der in Firefox zu löschenden Ursprünge basiert auf unserer Tracking-Schutzliste; WebKit verlässt sich auf die Klassifizierung von ITP.
• In Firefox umfasst die Definition von "Interaktion" das Scrollen des Benutzers beim Besuch des Ursprungs als First-Party; bei WebKit ist dies nicht der Fall.
• Firefox wird Daten für einen Ursprung nicht löschen, wenn er innerhalb der letzten 45 Kalendertage als First-Party eine Interaktion erhalten hat; das Interaktionsfenster von WebKit beträgt 30 Tage der Browsernutzung (z.B. Tage, an denen der Benutzer mindestens eine Interaktion mit Safari hatte).