Wie Digital-Footprint-Tracking im Detail funktioniert

Jedes Gerät, das sich mit dem Internet verbindet, hinterlässt eine Spur technischer Artefakte – einen digitalen Fußabdruck. Bei tracio.ai rekonstruieren wir diesen Fußabdruck aus über 130 passiven Signalen, die während eines einzigen Seitenaufrufs erfasst werden, ohne auf Cookies, localStorage oder irgendeine Form persistenter clientseitiger Speicherung zu setzen. Dieser Artikel erklärt genau, wie dieser Prozess funktioniert.

Die Schicht der Signalerfassung

Wenn unser JavaScript-Agent im Browser eines Besuchers geladen wird, beginnt er, Signale über mehrere Kategorien hinweg gleichzeitig zu erfassen. Canvas-Rendering, WebGL-Parameterabfragen, AudioContext-Verarbeitung, Schriftarten-Enumeration und das Auslesen von navigator-Eigenschaften laufen alle parallel. Der gesamte Erfassungsprozess ist auf moderner Hardware in unter 50 Millisekunden abgeschlossen.

Die entscheidende Erkenntnis ist, dass jedes Signal einen anderen Aspekt des Hardware- und Software-Stacks des Geräts erfasst. Das Canvas-Rendering spiegelt die GPU, den Treiber und die Font-Rendering-Engine wider. WebGL-Parameter offenbaren das Grafikkartenmodell und dessen Fähigkeiten. AudioContext zeigt Unterschiede darin, wie der Audio-DSP Fließkommaoperationen verarbeitet. Navigator-Eigenschaften melden CPU-Kerne, Arbeitsspeicher, Plattform und Spracheinstellungen.

Unser Team hat dies im vergangenen Monat über 2 Milliarden Ereignisse hinweg gemessen: Die mediane Erfassungszeit lag bei 38ms, das 99. Perzentil bei 52ms. Wir haben tatsächlich zunächst den naiven Ansatz ausprobiert – die Signale sequenziell zu erfassen. Er war 40-mal langsamer. Die parallele Erfassung mit einer Timeout-Absicherung war eine der ersten architektonischen Entscheidungen, die wir richtig getroffen haben.

TLS-Fingerprinting: die erste Schicht

Bevor unser JavaScript überhaupt ausgeführt wird, hat der Browser bereits über den TLS-Handshake erhebliche Informationen preisgegeben. Die Client-Hello-Nachricht enthält die Cipher Suites, die der Browser unterstützt, die TLS-Erweiterungen, die er verwendet, die elliptischen Kurven, die er bevorzugt, und die Signaturalgorithmen, die er akzeptiert. Diese Informationen werden durch die TLS-Bibliothek des Browsers bestimmt und variieren erheblich zwischen Browserfamilien, Versionen und Betriebssystemen.

Wir erfassen diesen TLS-Fingerprint mittels JA4-Hashing – einem modernen Ersatz für JA3, der eine bessere Granularität und versionsübergreifende Stabilität bietet. Der JA4-Hash allein kann Chrome von Firefox von Safari unterscheiden und grenzt die Identifikation oft auf einen bestimmten Browser-Versionsbereich ein. Kombiniert mit unseren clientseitigen Signalen bietet er eine Cross-Validierungsschicht, die außerordentlich schwer zu fälschen ist.

Canvas- und GPU-Fingerprinting

Canvas-Fingerprinting nutzt die Tatsache aus, dass verschiedene GPUs dieselben Zeichenanweisungen mit subtilen Unterschieden auf Pixelebene rendern. Die Canvas API erlaubt es uns, eine sorgfältig gestaltete Szene zu zeichnen – bestimmte Textzeichenfolgen in mehreren Schriftarten, geometrische Formen mit bestimmten Koordinaten und Farbverläufe mit präzisen Farbstopps – und anschließend einen Hash der resultierenden Pixeldaten zu berechnen.

Die Rendering-Unterschiede resultieren aus Variationen in den Anti-Aliasing-Algorithmen, dem Sub-Pixel-Rendering, der Farbmischung und dem Font-Hinting über GPU-Modelle und Treiberversionen hinweg. Selbst zwei Geräte mit demselben GPU-Modell können unterschiedliche Canvas-Ausgaben erzeugen, wenn sie unterschiedliche Treiberversionen oder Betriebssysteme verwenden. Das macht den Canvas-Hash zu einem unserer unterscheidungsstärksten Signale.

WebGL-Hardwareprofilierung

Die WebGL API gibt detaillierte Informationen über das Grafiksubsystem preis, die weit über die Renderer- und Vendor-Strings hinausgehen. Wir fragen maximale Texturgrößen, Shader-Präzisionsformate, unterstützte Erweiterungen, Viewport-Abmessungen und Dutzende weiterer Parameter ab, die über GPU-Modelle und Treiberkonfigurationen hinweg variieren.

Die Kombination dieser Parameter erzeugt ein detailliertes Hardwareprofil. Ein Gerät mit einer NVIDIA RTX 4070 etwa meldet andere maximale Texturgrößen, eine andere Shader-Präzision und eine andere Erweiterungsunterstützung als ein Gerät mit einer AMD RX 7800 XT. Dieses Hardwareprofil ist von Natur aus stabil – es ändert sich nicht mit Browser-Updates, sondern nur bei Hardware- oder Treiberänderungen.

Audio-Processing-Fingerprinting

Die Web Audio API stellt eine weitere hardwareabhängige Signalquelle bereit. Wir erzeugen einen Oszillatorknoten, verbinden ihn mit einem Dynamik-Kompressor und messen den Ausgabepuffer. Unterschiede in der Fließkommapräzision, der DSP-Implementierung und den Resampling-Algorithmen über Audio-Hardware und Betriebssysteme hinweg erzeugen messbare Variationen in der Ausgabe.

Audio-Fingerprints haben eine moderate Eindeutigkeit, aber eine außergewöhnliche Stabilität. Die Audioverarbeitungspipeline ändert sich selten, es sei denn, der Nutzer wechselt die Audio-Hardware oder installiert das Betriebssystem neu. Das macht Audiosignale zu wertvollen Ankern in unserem mehrstufigen Identifikationssystem.

Signalfusion und Identitätsauflösung

Rohsignale werden verschlüsselt und an unseren Server übertragen, wo die Geräteidentifikations-Engine sie durch ein dreistufiges Hashing-System verarbeitet. Signale auf Hardware-Ebene (Canvas, WebGL, Audio) bilden Tier 1 – die stabile Kernidentität. Signale auf Browser-Ebene (Feature-Erkennung, CSS-Eigenschaften, Media-Fähigkeiten) bilden Tier 2 und werden durch sessionübergreifendes Matching verarbeitet, um die erwartete Drift durch Browser-Updates aufzufangen. Volatile Signale (User-Agent, Zeitzone, Sprache) bilden Tier 3 und tragen zum Konfidenz-Scoring bei, ohne die Identitätsentscheidungen zu steuern.

Der Fusionsalgorithmus gewichtet jedes Signal nach seiner Eindeutigkeit und Stabilität. Eine Übereinstimmung bei einem seltenen Canvas-Hash trägt weitaus mehr Gewicht als eine Übereinstimmung bei einer verbreiteten Bildschirmauflösung. Dieser gewichtete Ansatz stellt sicher, dass die Identifikation auch dann genau bleibt, wenn sich eine Teilmenge der Signale ändert.

Keine Speicherung, keine Cookies

Ein entscheidendes Designprinzip unseres Systems ist, dass die Identifikation von keinerlei clientseitiger Speicherung abhängt. Wir setzen keine Cookies, schreiben nicht in localStorage und nutzen kein IndexedDB zu Tracking-Zwecken. Die Besucher-ID wird vollständig aus den inhärenten Eigenschaften des Geräts abgeleitet – der Hardware, dem Software-Stack, der Netzwerkkonfiguration. Das bedeutet, dass die Identifikation das Löschen von Cookies, den Inkognito-Modus und sogar die Neuinstallation des Browsers übersteht.

Datenschutz durch Architektur

Weil wir nur technische Browser-Attribute erfassen – keinen Browserverlauf, keine Formulardaten, keine persönlichen Inhalte –, ist die Auswirkung auf den Datenschutz minimal. Die W3C Fingerprinting Guidance umreißt Best Practices für die verantwortungsvolle Nutzung von Browser-Signalen, und unsere Architektur steht im Einklang mit diesen Prinzipien. Mit cloud-gehostetem Deployment findet die gesamte Verarbeitung auf Ihrer Infrastruktur statt. Keine Besucherdaten erreichen jemals unsere Server. Diese Architektur macht die Einhaltung von DSGVO, CCPA und anderen Datenschutzvorschriften unkompliziert.