Eine auf der IMC 2024 veröffentlichte Studie machte die Erkennung zu einem reproduzierbaren Online-Experiment: Statt der Selbstauskunft des Browsers zu vertrauen, zählte sie Eigenschaften interner Objekte und verglich sie mit der angegebenen Version. Die Methode ist aufschlussreicher als das Ergebnis.
Zur Frage, ob Browser-Fingerprints erkannt werden können, gibt es viele Behauptungen, die meist bei einem Ergebnis stehen bleiben. Statt darüber zu streiten, wer gewinnt oder verliert, lohnt sich ein Blick darauf, wie Forschende daraus ein reproduzierbares Experiment gemacht haben und anhand welcher Kennzahlen sie urteilen.
Eine auf der ACM Internet Measurement Conference (IMC) 2024 veröffentlichte Studie mit dem Titel Browser Polygraph wurde von Forschenden der Arizona State University, der Boston University und von Amazon durchgeführt; die DOI lautet 10.1145/3646547.3688455. Statt im Labor mit simulierten Daten zu arbeiten, wurde das Verfahren 4,5 Monate lang in der realen Produktionsumgebung eines großen Finanzunternehmens eingesetzt und erfasste 205.000 echte Nutzersitzungen. Untersucht wurden zehn verbreitete Lösungen zur Tarnung von Browserumgebungen, während normaler Nutzerverkehr als Kontrollgruppe diente.
Wie das Experiment aufgebaut wurde
Drei Gestaltungsentscheidungen machten es möglich, die Erkennung auf den gesamten Datenverkehr anzuwenden, ohne den Geschäftsbetrieb zu beeinträchtigen.
Die Merkmale mussten günstig zu erfassen sein. Die Erkennung liest nur eine feste Gruppe von Eigenschaften aus; der Aufwand pro Durchlauf liegt im Bereich von Millisekunden und KB. Dadurch kann sie auf den gesamten Verkehr angewendet werden, ohne Stichproben und ohne spürbare Auswirkungen für Nutzer.
Die Merkmale mussten stabil sein. Ausgewählt wurden nicht Parameter, die Nutzer verändern können, sondern interne Strukturen, die durch den Browser selbst vorgegeben sind. Jede Browserversion bringt eine andere JavaScript-Engine mit, und zwischen Versionen gibt es kleine Unterschiede bei der Anzahl vorhandener APIs und der Eigenschaften einzelner Objekte. Die Studie verwendete den Bereich von Chrome 110 bis Chrome 114 als Vergleich: Das System zählte die Eigenschaften von 28 zentralen Objekten und verglich das Ergebnis mit der vom Browser angegebenen Versionsnummer. Stimmen beide nicht überein, kommen Deklaration und tatsächliches Verhalten nicht aus derselben technischen Grundlage.
Die Labels mussten verlässlich sein. Jede getestete Umgebung wurde nacheinander an denselben Produktionsverkehr angebunden und nach denselben Regeln bewertet; die Kontrollgruppe bestand aus normalem Verhalten realer Nutzer. Das Ergebnis beschreibt daher nicht subjektiv, ob etwas „echt aussieht“, sondern ob sich dieser Verkehr unter denselben Regeln unterscheiden lässt.
Kennzahlen dafür, ob die Simulation wirklichkeitsgetreu ist
Die in der Studie verwendeten Messgrößen lassen sich in vier Gruppen einteilen.
- Konsistenz: Passt die vom Browser angegebene Version zur Struktur seiner internen Objekte? Das ist die wichtigste Kennzahl und zugleich am schwersten zu fälschen, weil das Ändern einer Zeichenfolge nicht automatisch die Zahl der Objekte und Eigenschaften in der Engine verändert.
- Erkennungsrate: Für vier der Lösungen führte die Studie detaillierte Tests durch; die Erkennungsrate lag zwischen 67 % und 84 %.
- Abweichung von realen Geräten: Unter denselben Entscheidungsregeln erhielten normale Browser einen Risikowert von 0, die getesteten Lösungen lagen im Mittel zwischen 8,85 und 11,66. Der Wert beschreibt den Abstand zur realen Verteilung und nicht einen subjektiven Eindruck von Ähnlichkeit.
- Unterscheidbarkeit: Lässt sich der getestete Verkehr vom normalen Verkehr trennen? Eine Kategorie, die nicht getrennt werden kann, zeigt unter dieser Methode keine Verhaltenslücke zu echten Browsern.
Von den vier Kennzahlen ist die erste die Ursache; die drei folgenden sind ihre Auswirkungen.
Woran die vier Ergebniskategorien jeweils scheitern
Die Studie teilte die getesteten Lösungen nach ihrer grundlegenden Implementierung in vier Kategorien ein.
In der ersten Kategorie passen die Merkmale der unteren Ebene zu keiner bekannten echten Browserversion. Es gibt also keine entsprechende Engine; eine einfache Prüfung macht die Abweichung sichtbar.
In der zweiten Kategorie enthält die Umgebung echte Fingerprint-Merkmale, doch beim Wechsel der Identität ändert sich nur die sichtbare Versionsangabe, während die zugrunde liegende Engine gleich bleibt. Dieses Muster war in der Studie am häufigsten. Bildlich gesprochen steht auf der Visitenkarte eine neue Version, aber der Akzent klingt noch alt. Das Problem liegt nicht darin, wie gut einzelne Parameter eingestellt sind, sondern in der Lücke zwischen Deklaration und Verhalten; genau daraus stammt ein großer Teil der Erkennung.
In der dritten Kategorie wechselt die zugrunde liegende Engine zusammen mit der Identität. Gibt sich die Umgebung als eine bestimmte Version aus, läuft auch die dazugehörige Engine. Die Konsistenz bleibt damit erhalten, und unter dieser Erkennung ließ sich der Verkehr nicht unterscheiden. Die Studie weist zugleich darauf hin, dass zur Erkennung dieser Kategorie komplexere Verfahren nötig sind.
Die vierte Kategorie verändert den Browser selbst nicht. Stattdessen läuft ein echter Browser in einer virtuellen Maschine und lädt anschließend die Zielkonfiguration. Weil der Browser tatsächlich echt ist, kann ihn die Erkennung nicht unterscheiden; der Betriebsaufwand ist jedoch hoch und schwer zu skalieren.
Der Unterschied zwischen den vier Kategorien liegt nicht in der Zahl der Parameter, sondern darin, ob Deklaration und Verhalten aus derselben technischen Grundlage stammen.
Praktische Hinweise zur Auswahl einer Umgebungslösung
Der Schwerpunkt der Erkennung hat sich vom Auslesen von Angaben zur Prüfung des Verhaltens verschoben. Änderbare Parameter an der Oberfläche bieten daher immer weniger Vorteil. Für die konkrete Bewertung gilt:
- Fragen Sie nach der unteren Ebene, nicht nach der Parameterliste. Ändert sie sich mit, wenn die Versionsangabe gewechselt wird? Werden Fingerprints automatisch als reale Kombinationen erzeugt oder als einzelne Werte manuell zusammengesetzt?
- Vergleichen Sie die Umgebungen miteinander. Wenn mehrere Umgebungen stark übereinstimmende Merkmale der unteren Ebene zurückgeben, ist die Isolation nicht vollständig.
- Erst Konsistenz, dann Differenzierung. Je mehr intern widersprüchliche Merkmale angepasst werden, desto größer wird die Angriffsfläche für Erkennung.
- Das Bestehen einer allgemeinen Erkennungsseite bedeutet nicht, dass eine Plattform die Umgebung akzeptiert. Am Ende sollte eine kleine Menge realen Verkehrs zur eigenen Validierung verwendet werden.
Die Kernaufgabe der Umgebungsisolation besteht darin, jede Umgebung in sich konsistent und eigenständig zu machen. Genau daran arbeitet PurpleMark. Erkennung und Gegenmaßnahmen sollten stets innerhalb rechtlicher und regelkonformer Grenzen eingesetzt werden; der eigentliche Wert dieser Studie liegt darin, Bewertungen auf eine nachvollziehbare Grundlage zu stellen, statt eine Rangliste von guten und schlechten Produkten zu liefern.
