Wir haben einen stabilen Firefox-Identifikator entdeckt, der alle privaten Tor-Identitäten eines Nutzers verknüpfen kann

• Allein über die Rückgabereihenfolge von indexedDB.databases() lässt sich in Firefox-basierten Browsern ein stabiler Identifikator erzeugen, der während der gesamten Prozesslaufzeit bestehen bleibt
• Dieser Identifikator wird über Origin-Grenzen hinweg geteilt, sodass auch nicht miteinander verbundene Websites innerhalb derselben Browser-Laufzeit denselben Wert beobachten und für Cross-Origin-Tracking nutzen können
• Im Private Browsing von Firefox bleibt der Identifikator erhalten, solange der Prozess weiterläuft, selbst nachdem alle privaten Fenster geschlossen wurden; im Tor Browser bleibt er sogar nach New Identity bestehen
• Die Ursache liegt darin, dass Geckos IndexedDB-Implementierung private Datenbanknamen auf UUID-basierte Dateinamen abbildet und das Ergebnis unsortiert offenlegt
• Mozilla hat den Fix in Firefox 150 und ESR 140.10.0 ausgeliefert; ein Design, das die interne Speicherreihenfolge nicht nach außen sichtbar macht, ist für den Schutz der Privatsphäre entscheidend

---

Überblick über die Schwachstelle

• In allen Firefox-basierten Browsern lässt sich über die Reihenfolge der von indexedDB.databases() zurückgegebenen Einträge ein Identifikator extrahieren, der für die Dauer des Prozesses stabil bleibt
  • Wenn eine Website mehrere IndexedDB-Datenbanken anlegt und danach die Rückgabereihenfolge prüft, kann sie einen eindeutigen und deterministischen Identifikator für den laufenden Browser-Prozess erzeugen
  • Dieses Verhalten tritt nicht im Origin-Kontext, sondern im Prozesskontext auf; selbst nicht miteinander verbundene Websites können innerhalb derselben Browser-Laufzeit denselben Identifikator beobachten
• Im Private Browsing von Firefox bleibt der Identifikator erhalten, wenn der Firefox-Prozess nach dem Schließen aller privaten Fenster weiterläuft
  • Im Tor Browser bleibt der stabile Identifikator sogar nach New Identity bestehen, also nachdem Cookies und Verlauf gelöscht und ein neuer Tor-Circuit verwendet wurden
  • Das steht im Widerspruch zur Erwartung, dass spätere Browser-Aktivitäten nicht mit früheren Aktivitäten verknüpft werden können, und schwächt die vom Nutzer erwartete Unverkettbarkeit
• Verantwortungsvolle Offenlegung gegenüber Mozilla und dem Tor Project
  • Mozilla hat den Fix in Firefox 150 und ESR 140.10.0 ausgeliefert
  • Der Patch wird unter Mozilla Bug 2024220 verfolgt; die Ursache liegt in Geckos IndexedDB-Implementierung und betrifft daher auch den Tor Browser und andere Firefox-basierte Browser
• Das Prinzip des Fixes ist einfach
  • Der Browser darf die interne Speicherreihenfolge im Prozesskontext nicht nach außen offenlegen
  • Wenn die Ergebnisse normalisiert oder sortiert zurückgegeben werden, lässt sich die Entropie entfernen und der Missbrauch als stabiler Identifikator verhindern

Warum das wichtig ist

• Private-Browsing-Modi und datenschutzorientierte Browser sollen es erschweren, Nutzer über unterschiedliche Kontexte hinweg zu identifizieren
  • Allgemeine Erwartung 1: Solange es keinen gemeinsamen Speicher oder explizite Identitätsmechanismen gibt, sollten nicht miteinander verbundene Websites nicht erkennen können, ob sie mit derselben Browser-Instanz interagieren
  • Allgemeine Erwartung 2: Wenn eine private Sitzung endet, sollten auch die mit dieser Sitzung verknüpften Informationen verschwinden
• Dieses Verhalten bricht beide Erwartungen
  • Websites können einen Identifikator allein aus dem internen Speicherverhalten des Browsers ableiten, ohne Cookies, localStorage oder explizite Cross-Site-Kanäle
  • Die Reihenfolge der von der API zurückgegebenen Datenbanknamen liefert ein starkes Identifikationssignal
• Daraus ergibt sich auch eine Lehre für Entwickler
  • Datenschutzschwachstellen entstehen nicht nur durch direkten Zugriff auf identifizierende Daten
  • Auch deterministisch offengelegte Implementierungsdetails können zu Datenschutzlecks führen
• Der zentrale Punkt aus Sicht von Sicherheit und Produktdesign
  • Selbst scheinbar harmlose APIs können zu einem Cross-Site-Tracking-Vektor werden, wenn sie stabilen Zustand auf Prozessebene offenlegen

IndexedDB und indexedDB.databases()

• IndexedDB ist eine Browser-API zur clientseitigen Speicherung strukturierter Daten
  • Webanwendungen nutzen sie für Offline-Unterstützung, Caching, Sitzungszustand und andere lokale Speicherzwecke
  • Jede Origin kann eine oder mehrere benannte Datenbanken anlegen und darin Object Stores sowie große Datenmengen speichern
• indexedDB.databases() gibt Metadaten zu den Datenbanken zurück, die für die aktuelle Origin sichtbar sind
  • Entwickler können damit bestehende Datenbanken prüfen, die Speichernutzung debuggen oder den Anwendungszustand verwalten
• Unter normalen Datenschutzannahmen sollte bereits die Rückgabereihenfolge dieser API keine identifizierenden Informationen enthalten
  • Erforderlich wäre eine neutrale oder normalisierte Darstellung der Datenbank-Metadaten
  • Das eigentliche Problem war, dass die Rückgabereihenfolge in Firefox-basierten Browsern eben nicht neutral war

Wie indexedDB.databases() zu einem stabilen Identifikator wurde

• Im Firefox Private Browsing gibt indexedDB.databases() Metadaten nicht in der Reihenfolge der Erstellung zurück, sondern in einer Reihenfolge, die aus der internen Speicherstruktur abgeleitet ist
  • Die relevante Implementierung befindet sich in dom/indexedDB/ActorsParent.cpp
• Im Private Browsing werden Datenbanknamen nicht direkt als Platten-Identifikatoren verwendet
  • Stattdessen werden sie über die globale Hashtabelle StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString> auf eine UUID-basierte Dateinamenbasis abgebildet
  • Dieses Mapping erfolgt in GetDatabaseFilenameBase() innerhalb von OpenDatabaseOp::DoDatabaseWork()
• Wenn aIsPrivate auf true steht, wird der von der Website gelieferte Datenbankname durch eine erzeugte UUID ersetzt und in der globalen StorageDatabaseNameHashtable gespeichert
  • Als Schlüssel wird nur die Datenbanknamenszeichenkette verwendet
  • Das Mapping bleibt für die Lebensdauer des IndexedDB QuotaClient bestehen
  • Es wird zwischen allen Origins geteilt
  • Es wird nur bei einem vollständigen Neustart von Firefox zurückgesetzt
• Bei späteren Aufrufen von indexedDB.databases() sammelt Firefox in GetDatabasesOp::DoDatabaseWork() über QuotaClient::GetDatabaseFilenames(...) die Datenbank-Dateinamen ein
  • Die Datenbank-Basisnamen werden in ein nsTHashSet eingefügt
  • Vor der Iteration findet keinerlei Sortierung statt
• Die endgültige Reihenfolge wird dadurch bestimmt, wie das Bucketing des Hash-Sets intern durchlaufen wird
  • Da das UUID-Mapping über die Lebensdauer des Firefox-Prozesses stabil bleibt, bleibt auch die Rückgabereihenfolge als deterministische Funktion der erzeugten UUID-Werte, des Verhaltens der Hash-Funktion, der Kapazität der Hashtabelle und der Einfügehistorie stabil
  • Diese Reihenfolge bleibt über Tabs und private Fenster hinweg erhalten und wird nur bei einem vollständigen Firefox-Neustart zurückgesetzt
  • Sowohl das UUID-Mapping als auch die Iteration über das Hash-Set sind nicht auf die Origin beschränkt, sondern wirken im Prozesskontext

Reproduktion

• Das Verhalten lässt sich bereits mit einer einfachen PoC nachweisen
  • Zwei unterschiedliche Origins hosten dasselbe Skript
  • Jedes Skript erzeugt Datenbanken mit einem festen Satz von Namen, ruft indexedDB.databases() auf und extrahiert sowie protokolliert die Rückgabereihenfolge
• In betroffenen Firefox-Private-Browsing- und Tor-Browser-Builds beobachten beide Origins während derselben Browser-Prozesslaufzeit dieselbe Permutation
  • Nach einem Browser-Neustart ändert sich die Permutation
• Beispiel für eine konzeptionelle Ausgabe
  • Erzeugungsreihenfolge: a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p
  • Rückgabereihenfolge: g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k
• Entscheidend ist nicht die exakte Reihenfolge selbst
  • Sie unterscheidet sich von der ursprünglichen Erzeugungsreihenfolge
  • Dieselbe Reihenfolge erscheint bei nicht verbundenen Origins
  • Sie bleibt bei Reloads, in neuen privaten Fenstern und sogar nach dem Schließen aller privaten Fenster bestehen
  • Erst ein vollständiger Browser-Neustart erzeugt eine neue Reihenfolge
  • Damit lässt sich die aus Datenschutzsicht unerwünschte Eigenschaft direkt beobachten

Auswirkungen auf die Privatsphäre

• Diese Schwachstelle ermöglicht innerhalb einer einzelnen Browser-Laufzeit sowohl Cross-Origin-Tracking als auch Same-Origin-Tracking

• Cross-Origin-Auswirkungen

  • Nicht miteinander verbundene Websites können unabhängig voneinander denselben Identifikator ableiten und daraus schließen, dass sie mit demselben laufenden Firefox- oder Tor-Browser-Prozess interagieren
  • Dadurch lassen sich Aktivitäten über Domains hinweg verknüpfen, selbst ohne Cookies oder andere gemeinsam genutzte Speicher

• Same-Origin-Auswirkungen

  • Im Firefox Private Browsing bleibt der Identifikator erhalten, solange der Firefox-Prozess weiterläuft, selbst nachdem alle privaten Fenster geschlossen wurden
  • Eine Website kann dadurch spätere Besuche wiedererkennen, obwohl sie wie eine neue private Sitzung erscheinen
  • Im Tor Browser untergräbt der stabile Identifikator die Isolation durch New Identity innerhalb des laufenden Browser-Prozesses praktisch vollständig
  • Dadurch können Sitzungen miteinander verknüpft werden, die vollständig getrennt sein sollten

• Warum das im Tor Browser besonders schwer wiegt

  • Der Tor Browser ist darauf ausgelegt, Cross-Site-Verknüpfbarkeit zu reduzieren und Identifikatoren auf Browser-Instanzebene zu minimieren
  • Ein stabiler Identifikator, der über die Prozesslaufzeit bestehen bleibt, steht in direktem Widerspruch zu diesem Designziel
  • Selbst wenn er nur bis zum vollständigen Neustart des Prozesses überlebt, reicht das aus, um die Unverkettbarkeit bei aktiver Nutzung spürbar zu schwächen

Entropie und Fingerprinting-Kapazität

• Dieses Signal ist nicht nur stabil, sondern hat auch hohe Kapazität
  • Wenn eine Website N Datenbanknamen kontrolliert, ist die Zahl der beobachtbaren Permutationen N!
  • Die theoretische Entropie beträgt log2(N!)
• Bei 16 kontrollierbaren Namen liegt der theoretische Raum bei etwa 44 Bit
  • Das reicht aus, um gleichzeitig laufende Browser-Instanzen in realen Umgebungen zu unterscheiden
• Wegen des Verhaltens der internen Hashtabellen kann die tatsächlich erreichbare Zahl von Permutationen etwas geringer sein
  • Aus Sicherheitssicht ändert das aber nichts am Kernproblem
  • Die offengelegte Reihenfolge liefert weiterhin genügend Entropie, um als starker Identifikator zu funktionieren

So wurde das Problem behoben

• Die korrekte Behebung besteht darin, die Offenlegung von Entropie, die aus dem internen Speicherlayout abgeleitet ist, zu unterbinden
  • Die sauberste Gegenmaßnahme ist, die Ergebnisse in einer kanonischen Reihenfolge zurückzugeben, etwa lexikografisch sortiert
  • So bleibt die API für Entwickler nützlich, während das Fingerprinting-Signal verschwindet
• Alternativ könnte die Ausgabe bei jedem Aufruf randomisiert werden, um die stabile Reihenfolge zu verbergen
  • Sortierung ist jedoch einfacher, vorhersagbarer und für Entwickler leichter verständlich
• Ideale Anforderungen an den Fix aus Sicht der Security-Entwicklung
  • geringe konzeptionelle Komplexität
  • minimales Kompatibilitätsrisiko
  • direkte Beseitigung des Datenschutzlecks

Verantwortungsvolle Offenlegung

• Verantwortungsvolle Offenlegung gegenüber Mozilla und dem Tor Project
  • Mozilla hat den Fix in Firefox 150 und ESR 140.10.0 ausgeliefert
  • Der Patch wird unter Mozilla Bug 2024220 verfolgt
• Die Wurzel des Verhaltens liegt in Geckos IndexedDB-Implementierung
  • Auch abgeleitete Gecko-basierte Browser einschließlich Tor Browser sind betroffen, sofern sie keine eigene Gegenmaßnahme haben

Datenschutzorientiertes Design

• Schon kleine Implementierungsdetails können zu erheblichen Datenschutzproblemen führen
  • Nicht miteinander verbundene Websites können Aktivitäten über Origins hinweg während derselben Browser-Laufzeit verknüpfen
  • Der Identifikator lebt länger als Nutzer erwarten und schwächt damit die Grenzen privater Sitzungen
• Positiv ist, dass sich das Problem einfach und wirksam beheben lässt
  • Wenn die Ausgabe vor der Rückgabe normalisiert wird, lässt sich diese Entropiequelle entfernen
  • Damit können die erwarteten Datenschutzgrenzen wiederhergestellt werden
• Es handelt sich um eine leicht zu übersehende, aber folgenreiche Art von Schwachstelle, die bei der Entwicklung datenschutzsensibler Funktionen besondere Aufmerksamkeit verdient

[GN⁺]

Hacker-News-Kommentare

• Ich fand diese Forschung wirklich beeindruckend, und der Text war auch sehr gut geschrieben.
  Am Ende hatte ich schon mit Produktwerbung gerechnet, war dann aber eher überrascht, dass keine kam.
  Wenn dieses Unternehmen mit seinem Produkt selbst Fingerprinting betreibt, frage ich mich allerdings, warum es diese Schwachstelle an Mozilla gemeldet hat.
  Selbst wenn das unethisch wäre, wäre es geschäftlich nicht sinnvoller, so etwas für sich zu behalten, um sich von der Konkurrenz abzuheben?
  Ich habe jedenfalls fast nie gesehen, dass Bedrohungsakteure im Rahmen einer Responsible Disclosure ihre eigenen Zero-Days verbrennen.

  • Ich nutze in unserem Produkt keine Schwachstellen.
  • Ich denke, sie waren von Anfang an nicht auf diese Schwachstelle angewiesen, und wichtiger ist, dass sie durch die Veröffentlichung auch für andere unbrauchbar wird.

• Wie im Artikel beschrieben, kann der Identifikator bestehen bleiben, solange der Firefox-Prozess lebt. Daher sollte man den Tor Browser am Ende einer Sitzung unbedingt vollständig beenden.
  Ebenso wichtig ist es, innerhalb einer Sitzung nicht verschiedene Nutzungszwecke zu vermischen.

• Der von OP verlinkte Artikel lief in meiner Tor-Umgebung auf einen Timeout, aber die Wayback-Version ließ sich problemlos öffnen.
  Außerdem frage ich mich, ob es akademische Forscher gibt, die sich mit diesem Thema befassen.
  Ich kenne die Arbeit von Organisationen wie der EFF, suche aber eher nach Uni-Professoren oder reinen Forschungslabors wie MSR oder PARC als nach NGO-Aktivisten.
  Als jemand mit großem Interesse an Privatsphäre habe ich das Gefühl, mit meiner persönlichen Holy Trinity aus noscript, ublock origin und firefox containers zwar bei der Sicherheit einiges abdecken zu können, aber Anonymität entgleitet einem wegen Fingerprinting immer wieder.
  Wenn man Stylometrie weiter gefasst ebenfalls als Fingerprinting versteht, gilt das umso mehr.

  • Web-Fingerprinting ist ein Feld, das sowohl auf Angriffs- als auch auf Verteidigungsseite aktiv erforscht wird.
    Als Beispiel könnten Konferenzen wie PETS hilfreich sein.

• Ich frage mich schon grundsätzlich, wie Websites auf solche Informationen zugreifen können, ohne den Nutzer überhaupt zu fragen oder ihn darüber zu informieren.
  Warum sind Browser nicht eher wie Smartphones aufgebaut, bei denen Server oder Apps für den Zugriff auf solche Informationen eine Berechtigung anfordern müssen?

  • Browser-Fingerprinting ist eher ein Nebeneffekt der Funktionen, die Browser bereitstellen.
    Ein User-Agent, der die Browserversion mitteilt, ist einigermaßen vernünftig, und auch die Möglichkeit abzufragen, welche Schriftarten im System vorhanden sind, lässt sich wegen der Font-Unterstützung nicht einfach komplett entfernen.
    Zeitzone, Sprache, Tastaturlayout, Bildschirmgröße und Fenstergröße sind ebenfalls für normales Webverhalten nötig.
    Genauso ist es selbstverständlich, dass man wissen muss, welche Formate ein Video- oder Audioplayer unterstützt, um passende Medien auszuliefern.
    Solange JavaScript die Zeit auslesen kann, ist es außerdem leicht, durch Vergleich mit der Serverzeit Abweichungen der Systemuhr zu ermitteln.
    Wenn sich all das Stück für Stück aufsummiert, wird am Ende fast jeder Browser eindeutig identifizierbar.
  • Der meistgenutzte Browser wird von einer Werbefirma entwickelt.
    Und diese Firma finanziert zudem den größten Konkurrenten in erheblichem Umfang mit.
    Insofern überrascht mich diese Realität nicht.
  • Ich finde es trotzdem besser als bei Apps.
    Apps haben Zugriff auf viel mehr Identifikatoren und Geräteeigenschaften.
    Das gilt meiner Meinung nach selbst auf relativ gut geschützten Systemen ohne Google Play services.
  • Das erinnert mich an Telefone wie Android.
    Bei Apple fehlt es mir dagegen eher an feingranularer Kontrolle.
  • Zwischen Web-Benutzbarkeit, dem Verhindern von Fingerprinting und dem Vermeiden von Dutzenden oder Hunderten Berechtigungs-Pop-ups gibt es meiner Meinung nach eine sehr schmale Grenze.
    Da Browser inzwischen eine Komplexität haben, die fast an ein Betriebssystem heranreicht, kann praktisch jeder Teil des Systems unbeabsichtigt offengelegt und missbraucht werden.

• Der Ausdruck process-scoped im Text hat mich etwas verwirrt.
  Ich meine mich zu erinnern, dass Mozilla 2021 ein experimentelles One-Process-per-Site für Firefox vorgestellt und erklärt hatte, dass Desktop-Firefox dadurch für alle Websites Grenzen auf Ebene von Betriebssystemprozessen schafft.
  Der entsprechende Beitrag ist Introducing Site Isolation in Firefox.
  Deshalb frage ich mich, ob diese Funktion noch nicht vollständig ausgerollt wurde oder ob sie zwar ausgerollt ist, IndexedDB aber außerhalb dieser Isolation liegt.

  • Erst nachdem ich diesen Kommentar gelesen hatte, verstand ich es so, dass noch gewisse globale Verhaltensweisen übrig sind und genau dadurch Fingerprinting möglich wird.
    Wenn das so ist, finde ich die Erklärung ziemlich interessant.

• So wie es hier erklärt wird, klingt es so, als bliebe das Ganze nach einem Browser-Neustart nicht erhalten. Dann würde der Nutzen für Angreifer doch ziemlich sinken, oder?

  • Dieser im Artikel zitierte Teil erklärt das Risiko meiner Meinung nach gut:
    Im Firefox-Privatmodus kann der Identifikator erhalten bleiben, wenn zwar alle privaten Fenster geschlossen werden, der Firefox-Prozess selbst aber weiterläuft.
    Im Tor Browser bleibt ein stabiler Identifikator offenbar sogar dann erhalten, wenn man New Identity verwendet, also eigentlich einen vollständigen Reset mit gelöschten Cookies, gelöschter Chronik und neuer Tor-Verbindung beabsichtigt.
  • Das in so einer Situation verwendete Verfahren ist ID-Bridging.
    Zuerst fingerprintet eine Website den Browser und speichert eine ID zusammen mit dem Fingerprint im Cookie.
    In der nächsten Sitzung wird erneut fingerprintet und mit dem Cookie verglichen; wenn sich der Wert geändert hat, meldet der Server den alten und den neuen Fingerprint gemeinsam zurück und verknüpft sie so.
  • Viele Nutzer lassen ihren Browser monatelang geöffnet.
  • Ich bin nicht sicher, ob der Nutzen wirklich so stark sinkt.
    Behörden kennen oder überwachen vermutlich bereits viele Nodes, und wenn man mehrere Metadaten querverknüpft, kann man Personen ziemlich präzise identifizieren.
    Es muss auch nicht immer zu 100 Prozent exakt sein; oft reicht es schon, viele indirekte Informationen zu sammeln, also Daten nicht über das Ziel selbst, sondern etwa aus der Umgebung oder „durch die Wand“ gewissermaßen.
    Für mich fühlt sich das wie eine Art Identifikation über Proxy-Informationen an.

• Ehrlich gesagt wirken viele Web Standards so, als würden sie eher für Fingerprinting als für echte Funktionalität genutzt.
  IndexedDB scheint nur auf wenigen Websites wirklich als Speicher verwendet zu werden, und ich frage mich, wer es tatsächlich unbedingt braucht.
  Deshalb halte ich die Richtung, Webstandards immer weiter auszubauen, für falsch.
  Browser sollten nur minimale APIs für die Interaktion mit dem Gerät bereitstellen, und Funktionen wie IndexedDB könnte man auch als WebAssembly-Bibliotheken umsetzen, die keine wertvollen Daten preisgeben.
  Wenn etwa canvas nur Zugriff auf einen Bildpuffer gäbe, ohne Zeichenroutinen aufzurufen, die plattformspezifische Bibliotheken nutzen, wäre sein Wert fürs Fingerprinting meiner Meinung nach deutlich geringer.

  • Mit Browser-Erweiterungen wie „Local Storage Editor“ kann man sich den Inhalt des Local Storage einer Website direkt ansehen.
    In den Fällen, die ich bisher gesehen habe, wurde das etwa genutzt, um langlebige Bilder wie bei gmail zu cachen oder den Login-Zustand auf andere Weise als mit Cookies zu erhalten.

• Ich war hier etwas verwirrt.
  Wenn die UUID von IndexedDB über alle Origins hinweg geteilt wird, müsste man den Browser dann nicht über den Datenbankinhalt selbst identifizieren können statt über die Reihenfolge?

  • Auf der Seite gibt es ein leicht verständliches Beispiel.
    Wenn eine Seite die Datenbanken a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p anlegt und dann ihre Reihenfolge abfragt, kann sie aufgrund der globalen Name-UUID-Zuordnung zum Beispiel ein Ergebnis wie g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k erhalten.
    Die zentrale Schwachstelle ist, dass jede Website, die denselben Satz an Datenbanken anlegt, bei laufendem Firefox-Prozess genau dieselbe Reihenfolge sieht, unabhängig vom Inhalt.
    Dadurch entsteht ein stabiler, entropiereicher Identifikator über die Zeit hinweg, also ein Fingerprint.
    Er wird originsübergreifend geteilt, und selbst nach dem Löschen von Website-Daten kann man den Fingerprint wiedererlangen, indem man einfach Datenbanken mit denselben Namen neu anlegt und die Reihenfolge erneut ausliest.
  • Der Dateninhalt selbst ist natürlich auf die jeweilige Origin beschränkt.
    Sonst wäre IndexedDB ein viel zu einfacher Evercookie gewesen.
  • Browserübergreifend über Origins hinweg geteilt wird nicht der Datenbankinhalt, sondern die UUID-Zuordnung.
    Jeder Origin wird, soweit ich es verstehe, nur die Teilmenge der Datenbanken angezeigt, die mit diesem Origin verknüpft ist.

• Ich habe mich gefragt, ob der Tor Browser standardmäßig immer noch JavaScript erlaubt.
  So wie ich es verstehe, wäre man von dieser Schwachstelle nicht betroffen, wenn man die Ausführung von JavaScript blockiert.

  • Tatsächlich macht das Abschalten von JavaScript den Fingerprint oft noch auffälliger.
    Es gibt nicht viele Nutzer mit deaktiviertem JS, also landet man sofort in einer viel kleineren Gruppe und wird innerhalb dieser leichter einzigartig.
    Natürlich sinken ohne JS die Möglichkeiten, Detailinformationen zu sammeln, aber gleichzeitig wird man schon mit weniger Informationen leichter unterscheidbar.
    Außerdem spoofed der Tor Browser merkwürdigerweise navigator.platform überhaupt nicht, sodass eine Website trotz eines auf Windows getarnten User-Agents weiterhin erkennen kann, ob man Linux verwendet.