Ein Fingerprint ist eine Geschichte, keine Liste

Vom Wert zur Beziehung

Frühes Fingerprinting war eine Checkliste. Canvas, WebGL, Schriftarten, Bildschirmgröße und Zeitzone einsammeln, alles zusammen hashen, den Hash vergleichen. Passte er zu einem bekannten Negativwert, wurde blockiert.

Dieser Ansatz ist längst tot, aus einem einfachen Grund: Man schlug ihn, indem man Werte änderte. An seine Stelle trat die Korrelation zwischen Attributen — statt zu fragen, wie ein einzelner Wert lautet, fragt das System, ob die Werte zum selben Computer gehören können.

Das verändert den Schwierigkeitsgrad enorm. Einen Wert zu fälschen ist trivial. Vierzig Werte zu fälschen, die alle dieselbe Maschine ergeben, ist ein Modellierungsproblem — und genau daran scheitern die meisten Antidetect-Setups, weil ihre Oberfläche dazu einlädt, jedes Feld einzeln aus einem Dropdown zu wählen.

Du willst keinen ungewöhnlichen Fingerprint erzeugen. Du willst einen unauffälligen erzeugen — die plausible Beschreibung eines gewöhnlichen Computers, der zufällig nicht deiner ist.

Die Widersprüche, die geprüft werden

Das sind die Korrelationen, die in echter Erkennungslogik am häufigsten vorkommen. Keine ist exotisch, alle sind billig.

GPU gegen Plattform

Dein unmaskierter WebGL-Renderer-String nennt einen echten Chip und einen echten Treiberpfad. ANGLE (Apple, Apple M2, OpenGL 4.1) ist ein Mac. ANGLE (NVIDIA, NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0, D3D11) ist Windows — Direct3D gibt es sonst nirgends. Ein User Agent, der macOS behauptet, neben einem D3D11-Renderer ist kein seltenes Gerät; es ist ein unmögliches.

GPU gegen Bildschirm

Eine Maschine mit M-Serien-GPU und einem 1366×768-Bildschirm bei devicePixelRatio 1 existiert nicht — Apple hat dieses Panel in der fraglichen Zeit nicht ausgeliefert. Integrierte Grafik von vor zehn Jahren neben einem 3840×2160-Display ist ähnlich unwahrscheinlich. Erkennungsanbieter führen genau für solche Paare Verteilungstabellen.

Schriftarten gegen Betriebssystem

Schriftartensätze sind OS-Signaturen. Segoe UI kommt mit Windows. SF Pro und Helvetica Neue mit macOS. Ubuntu und die Liberation-Familie mit gängigen Linux-Distributionen. Ein „Windows“-Profil, das Segoe UI nicht rendern kann, ist an einer Prüfung gescheitert, die den Tracker einen einzigen measureText-Aufruf kostet. Die Schriftarten-Fläche verdient eine eigene Behandlung und bekommt sie auch.

Zeitzone gegen IP

Der häufigste Fehler überhaupt und der unbedarfteste. Intl.DateTimeFormat().resolvedOptions().timeZone liefert, was der Browser zu sein glaubt; die IP sagt, woher die Verbindung kommt. Eine brasilianische Privatanschluss-IP mit Europe/Rome ist eine Abweichung, die jeder Junior-Entwickler markieren würde. Schlimmer noch: Der Browser gibt auch den rohen getTimezoneOffset() preis, sodass ein Profil, das den IANA-Namen fälscht, aber nicht den Offset, sich ganz ohne externe Daten selbst widerspricht.

Sprache gegen alles

Es gibt drei Sprachflächen, und oft werden nur zwei davon gesetzt: der HTTP-Header Accept-Language, navigator.languages in JavaScript und die Locale, die die Intl-API auflöst. Wir haben Profile im Einsatz gesehen, die aus JavaScript it-IT meldeten und gleichzeitig en-US,en;q=0.9 im Header schickten. Das ist ein Konfigurationsfehler, der im Anfrage-Log sichtbar ist.

Hardwarezahlen gegen Geräteklasse

hardwareConcurrency und deviceMemory sollten eine Maschine beschreiben, die jemand tatsächlich gekauft hat. deviceMemory ist laut Spezifikation auf 0.25, 0.5, 1, 2, 4, 8 quantisiert — der Wert 6 ist nicht bloß ungewöhnlich, er ist spezifikationswidrig. Vierundsechzig logische Kerne neben 4 GB gemeldetem Speicher beschreiben nichts, was es zu kaufen gibt.

Touch gegen Bauform

maxTouchPoints > 0 bei einem Desktop-User-Agent, ohne passendes touchfähiges Geräteprofil, ist ein häufiger Rest aus dem Kopieren eines mobilen Fingerprints. Ebenso ein mobiler User Agent mit 1920×1080-Bildschirm und Mauszeiger.

Die Prüfung über zwei Kontexte

Über die paarweise Plausibilität hinaus gibt es einen strengeren Test, und er beendet Sitzungen: dieselbe Frage an zwei Stellen stellen und vergleichen.

Der Browser stellt mehrere Ausführungskontexte bereit, die alle dieselbe Maschine beschreiben sollten — das Hauptfenster, einen Web Worker, einen iframe und einen Service Worker. Ein Override auf Seitenebene erreicht typischerweise nur den ersten. Erkennungsskripte lesen hardwareConcurrency, deviceMemory, platform, userAgent und die WebGL-Strings aus einem Worker und vergleichen sie mit denen des Fensters.

Für eine Abweichung gibt es keine harmlose Erklärung. Das ist keine Heuristik mit einer Falsch-Positiv-Rate, das ist ein Beweis. Es ist das stärkste Argument dafür, Fingerprints in der Engine statt in einem eingeschleusten Skript zu behandeln, und im CDP-Artikel wird es vertieft.

Wo zufällige Profilgeneratoren scheitern

Werkzeuge, die einen „zufälligen Fingerprint“ erzeugen, ziehen meist jedes Feld unabhängig aus einer Liste plausibler Werte. Jedes einzelne Feld sieht gut aus. Die Kombination ist oft absurd.

Unabhängiges Ziehen erzeugt eine Mac-GPU mit einem Windows-Schriftartensatz, einen 4K-Bildschirm auf integrierter Grafik von 2014 oder einen Chrome-147-User-Agent mit einer userAgentData-Markenliste aus Chrome 131. Jeder Wert hat seine eigene Prüfung bestanden; die beschriebene Maschine existiert nicht.

Die Lösung ist, die Maschine zu ziehen, nicht die Felder. Beginne bei einem echten Gerätearchetyp — sagen wir einem ThinkPad von 2023 mit Iris-Xe-Grafik, 16 GB RAM, einem 1920×1080-Panel und dem Schriftartensatz von Windows 11 — und leite jeden Wert daraus ab. Variiere innerhalb der realistischen Spanne des Archetyps, nie über Archetypen hinweg.

Ein nützlicher Test für jedes Werkzeug: Leg zehn Profile an und lies ihren WebGL-Renderer und ihre Plattform. Bekommst du eine Apple-GPU neben Win32, zieht der Generator Felder.

Gewöhnlich schlägt einzigartig

Ein letzter Punkt, der dem Bauchgefühl widerspricht. Einzigartigkeit ist nicht das Ziel. Ein Fingerprint, der zu nichts Bekanntem passt, ist selbst ein Signal — er bedeutet, dass der Tracker diese Konfiguration noch nie gesehen hat, und so sieht kein gewöhnlicher Nutzer aus.

Der bequeme Platz ist die Mitte der Verteilung. Ein 1920×1080-Bildschirm, 8 oder 16 GB RAM, 8 logische Kerne, eine Mittelklasse-GPU, der Standard-Schriftartensatz des Betriebssystems und eine Zeitzone, die zur Exit-IP passt. In jeder Hinsicht langweilig — und mit Millionen anderer Maschinen geteilt.

Widersteh der Versuchung, beeindruckende Hardware zu wählen. Eine 32-Kern-Workstation mit 128 GB RAM ist einprägsam, und einprägsam ist das Gegenteil dessen, was du willst.

Eine Checkliste zum Durchgehen

Bevor du ein Profil in Betrieb nimmst, prüfe der Reihe nach diese Punkte. Jeder einzelne Fehlschlag gehört behoben, bevor es weitergeht:

1. IP-Geolokalisierung, timeZone und getTimezoneOffset() zeigen alle auf denselben Ort.
2. Accept-Language, navigator.languages und die aufgelöste Intl-Locale stimmen überein.
3. Der WebGL-Renderer nennt einen Chip, der mit der im User Agent genannten Plattform ausgeliefert wird.
4. Die Schriftartenliste ist der Standardsatz dieser OS-Version, plus nichts Exotisches.
5. Bildschirmauflösung und devicePixelRatio beschreiben ein Panel, das mit dieser GPU-Klasse ausgeliefert wurde.
6. deviceMemory ist ein zulässiger Wert, und hardwareConcurrency ist daneben plausibel.
7. Ein Web Worker liefert dieselben Werte wie das Fenster.
8. Der Canvas-Hash ist über Renderdurchgänge und Sitzungen hinweg stabil — siehe warum das zählt.
9. WebRTC meldet keine andere IP als die des Proxys. Dieses Leck passiert lautlos.
10. Die Marken in navigator.userAgentData passen zur Chrome-Hauptversion im User-Agent-String.

CreepJS erledigt das meiste davon für dich und sagt klar, welche Paare es für unstimmig hält. Führ es einmal pro Profilvorlage aus, nicht einmal pro Profil — ist die Vorlage sauber, sind es die daraus abgeleiteten Profile auch.