Hintergrund: ETag-Tracking ist hier hier gut erklärt und auch auf Wikipedia .
Eine Antwort schrieb ich in einer Antwort auf "Wie kann ich die Verfolgung durch ETags verhindern?" hat mich dazu getrieben, diese Frage zu schreiben.
Ich habe eine browserseitige Lösung, die ETag-Tracking verhindert. Es funktioniert ohne Änderung des aktuellen HTTP-Protokolls. Ist dies eine praktikable Lösung für ETag-Tracking?
Anstatt dem Server unseren ETag mitzuteilen, fragen wir den Server nach seinem ETag und vergleichen ihn mit dem, den wir bereits haben.
Pseudocode:
%Vor%HTTP-Konversationsbeispiel mit meiner Lösung:
Kunde:
%Vor%Server:
%Vor%Fall 1, Client hat ein identisches ETag:
%Vor%Fall 2, Client hat ein nicht übereinstimmendes ETag:
%Vor%Extras, die eine Änderung der HTTP-Spezifikation erfordern
Stellen Sie sich Folgendes als theoretisches Material vor: Die HTTP-Spezifikation wird sich wahrscheinlich in absehbarer Zeit nicht ändern.
1. Entfernen HEAD Overhead
Es ist erwähnenswert, dass es einen geringen Overhead gibt, der Server muss den HTTP-Header zweimal senden: Einmal als Antwort auf den HEAD und einmal als Antwort auf den GET. Eine theoretische Abhilfe hierfür besteht darin, das HTTP-Protokoll zu ändern und eine neue Methode hinzuzufügen, die Header-losen Inhalt anfordert. Dann würde der Client nur den HEAD und dann den Inhalt nur dann anfordern, wenn die ETags nicht übereinstimmen.
2. Cache-basiertes Tracking verhindern (oder zumindest viel schwieriger machen)
Obwohl das von Sneftel vorgeschlagene Workaround keine ETag-Tracking-Technik ist, verfolgt es Leute, selbst wenn sie die von mir vorgeschlagene "HEAD, GET" -Sequenz verwenden. Die Lösung würde die möglichen Werte von ETags einschränken: Anstatt irgendeine Sequenz zu sein, muss das ETag eine Prüfsumme des Inhalts sein. Der Client prüft dies, und falls zwischen dem Prüfsummenwert und dem vom Server gesendeten Wert eine Diskrepanz besteht, wird der Cache nicht verwendet.
Randnotiz: Fix 2 würde auch die folgenden Evercookie Tracking-Techniken eliminieren: pngData, etagData, cacheData . Kombiniert man das mit Chrome "Lokale Daten nur so lange speichern, bis ich meinen Browser beendet habe", werden alle evercookie-Tracking-Techniken außer Flash und Silverlight-Cookies eliminiert.
Es klingt vernünftig, aber es gibt Problemumgehungen. Angenommen, die Titelseite erhält immer die gleiche Etag-Nummer (so dass die wiederkehrenden Besucher sie immer aus dem Cache laden würden), aber die Seite selbst referenziert bei jedem Laden ein anders benanntes Bild. Ihre GET- oder HEAD-Anfrage für dieses Bild würde Sie dann eindeutig identifizieren. Es handelt sich vermutlich nicht um einen etag-basierten Angriff, aber Ihr Cache wird immer noch verwendet, um Sie zu identifizieren.
Solange Caching verwendet wird, gibt es auch bei den HTTP-Änderungen einen potenziellen Exploit. Angenommen, die Hauptseite enthält 100 Bilder, von denen jedes zufällig aus einem potenziellen Pool von 2 Bildern ausgewählt wurde.
Wenn ein Benutzer auf die Website zurückkehrt, lädt sein Browser die Seite neu (da die Prüfsumme nicht übereinstimmt). Im Durchschnitt werden 25 der 100 Bilder von zuvor im Cache gespeichert. Diese Kombination kann (fast sicher) verwendet werden, um den Benutzer individuell zu identifizieren.
Interessanterweise ist dies fast genau so, wie DNA-Vaterschaftstests funktionieren.
Der Server könnte feststellen, dass Sie für eine Anzahl von Ressourcen eine HEAD-Anfrage ausführen, auf die für dieselbe Ressource kein GET folgt. Das ist ein Unterschied, wenn Sie Poker spielen.
Nur wenn Sie einige Ressourcen zwischengespeichert haben, speichern Sie Informationen. Diese Informationen können vom Server jedes Mal abgeleitet werden, wenn Sie eine auf der Seite angegebene Ressource nicht erneut anfordern.
Wenn Sie Ihre Privatsphäre auf diese Weise schützen, müssen Sie bei jedem Besuch jede Ressource auf der Seite herunterladen. Wenn Sie jemals etwas zwischenspeichern, dann speichern Sie Informationen, die aus Ihren Anfragen auf den Server abgeleitet werden können.
Besonders auf mobilen Geräten, bei denen die Bandbreite teurer und oft langsamer ist, kann das Herunterladen aller Seitenressourcen bei jedem Besuch unpraktisch sein. Ich denke auf einer Ebene muss man akzeptieren, dass es Muster in der Interaktion mit der Website gibt, die erkannt und profiliert werden können, um Sie zu identifizieren.
Tags und Links http privacy etag tracking cookieless