Das Identifikationssystem von TRACIO erzeugt aus über 130 Browser-Signalen eine stabile Besucherkennung. Die Kennung bleibt über Sitzungen, den Inkognito-Modus, VPN-Wechsel und das Löschen von Cookies hinweg erhalten. Diese Seite erläutert die vollständige Identifikations-Pipeline.
Der Client erfasst über 130 verschiedene Browser-Signale in 10 Kategorien. Jedes Signal untersucht einen anderen Aspekt des Browsers und des Geräts – von Hardware-Merkmalen bis hin zum Rendering-Verhalten.
| Gruppe | Signale | Stabilität | Beispiele |
|---|---|---|---|
| Hardware | 12 | Sehr hoch | Bildschirmauflösung, Gerätespeicher, Hardware-Parallelität, Touch-Unterstützung |
| Rendering | 9 | Hoch | Canvas-Fingerprint (Text + Geometrie), WebGL-Renderer, Audio-Verarbeitung |
| Schriftarten | 5 | Hoch | Verfügbare Systemschriften (69 Familien getestet), Schrifteinstellungen, MathML-Rendering |
| Plattform | 25 | Mittel | User-Agent, Navigator-Eigenschaften, Zeitzone, Sprache, Anbieter |
| CSS-Engine | 10 | Mittel | Media-Query-Antworten (Farbschema, HDR, reduzierte Bewegung, erzwungene Farben) |
| Speicher | 10 | Mittel | Cookie-Unterstützung, localStorage, sessionStorage, Speicherkontingent |
| WebGL | 9 | Hoch | GPU-Anbieter, Renderer (unmaskiert), Shader-Präzision, Extension-Unterstützung |
| Netzwerk | 3 | Niedrig | Verbindungs-RTT, TURN-Probe, App-Version |
| Bot-Indikatoren | 15 | – | Webdriver-Flag, Automatisierungs-Frameworks, eval-Länge, Headless-Marker |
| Benutzerdefiniert | 14 | Variabel | Math-Fingerprint, WASM-Funktionen, Architektur-Erkennung |
Nicht alle Signale sind für die Identifikation gleich nützlich. Signale werden nach ihrer Stabilität klassifiziert:
Stufe 1 (Eingefroren): Hardware- und Rendering-Signale, die sich nahezu nie ändern. Canvas-Fingerprint, WebGL-Renderer, Audio-Fingerprint, GPU-Parameter, Schriftarten-Enumeration, mathematische Operationen, Architektur-Byte.
Stufe 2 (Halbstabil): Signale, die sich mit Browser-Updates oder Konfigurationsänderungen ändern. User-Agent, Client Hints, Plug-ins, CSS-Media-Queries, Speicherfähigkeiten.
Stufe 3 (Volatil): Signale, die sich häufig ändern. Bildschirmauflösung (Monitorwechsel), Zeitzone (Reisen), Spracheinstellungen, Verbindungseigenschaften.
Die Besucher-ID wird über ein dreistufiges Hashing-System berechnet, das Stabilität und Erweiterbarkeit ausbalanciert:
Visitor ID = [Tier1Hash][Tier2Hash][Tier3Hash] 20 chars 10 chars 10 chars ──────── ──────── ──────── base62 base62 base62Stufe 1 verwendet ausschließlich eingefrorene Signale, die der Hardware und der Rendering-Engine inhärent sind. Diese Signale ändern sich nur, wenn der Nutzer zu einem anderen physischen Gerät wechselt oder wesentliche Hardware-Änderungen vornimmt.
Enthaltene Signale: Canvas-Fingerprint-Hash, WebGL-Renderer (unmaskiert), WebGL-Anbieter (unmaskiert), Audio-Fingerprint, Schriftarten-Enumeration-Hash, WebGL-Parameter-Hash, Hash mathematischer Operationen, Architektur-Byte (ARM vs. x86).
Algorithmus:
key1=value1|key2=value2|... (Schlüssel alphabetisch sortiert)Stufe 1 ist bewusst eingefroren. Der Stufe 1 werden niemals neue Signale hinzugefügt, sodass der Identitätskern über Server-Updates hinweg stabil bleibt.
Stufe 2 erfasst die Browser- und Betriebssystemumgebung. Diese Signale ändern sich, wenn der Nutzer seinen Browser aktualisiert, Erweiterungen installiert oder Systemeinstellungen ändert.
Enthaltene Signale: User-Agent-Daten, Client Hints (Marken, Plattform, Architektur), Navigator-Eigenschaften (Anbieter, Plattform, Sprachen), Plug-in-Liste, Bildschirm-Farbtiefe, Gerätespeicher, Hardware-Parallelität.
Stufe 3 erfasst volatile Signale, die sich zwischen Sitzungen ändern können. Sie dienen der Konfidenzbewertung und dem Fuzzy-Matching, wirken sich jedoch nicht auf die Kernidentität aus.
Enthaltene Signale: Bildschirmauflösung, Zeitzone, Sprache, DOM-Blocker, Speicherfähigkeiten, CSS-Media-Query-Antworten, Verbindungseigenschaften.
Jede Stufe wird mit MurmurHash3-x64-128 gehasht, einer schnellen, nicht kryptografischen Hash-Funktion, die eine 128-Bit-Ausgabe erzeugt. Der Algorithmus:
MurmurHash3 bietet eine hervorragende Verteilung (jedes Bit der Eingabe beeinflusst jedes Bit der Ausgabe) und ist schnell genug für Echtzeitberechnungen. Es ist nicht kryptografisch sicher, was für das Hashen von Fingerprints aber auch nicht erforderlich ist.
Input: "canvas=abc123|webgl_renderer=ANGLE|audio=0.04852" ↓ MurmurHash3-x64-128Output: 0x7f4a8c2d1e3b5f6a 0x9d8c7b6a5e4f3d2c ↓ base62 encodeResult: "X7fh2Hg9LkMn3pQr5tBv"Der Konfidenzwert (0,0 bis 1,0) gibt an, wie sicher sich das System bei der Besucher-Identifikation ist:
Wenn das Cookie _vid_t mit einem bekannten Besucher übereinstimmt, wird die Konfidenz auf 1.0 gesetzt. Das Cookie enthält die UID des Besuchers, die der Server gegen seine Datensätze validiert. Dies ist der schnellste und zuverlässigste Identifikationspfad.
Neue Besucher ohne vorherigen Datensatz erhalten einen Konfidenzwert von 0.90. Es besteht kein Risiko einer falschen Zuordnung, da keine vorhandenen Datensätze zum Vergleich existieren.
Für wiederkehrende Besucher ohne Cookie-Treffer berechnet das System die Konfidenz aus:
Gewichtung nach Signalhäufigkeit (IDF): Signale, die über die globale Population hinweg einzigartiger sind, erhalten ein höheres Gewicht. Ein seltener WebGL-Renderer ist aussagekräftiger als eine verbreitete Bildschirmauflösung.
Fuzzy-Matching: Das System vergleicht den aktuellen Fingerprint anhand der bitweisen Hamming-Distanz mit gespeicherten Fingerprints. Die Signale werden nach Stufen gruppiert, und der Übereinstimmungswert jeder Stufe wird unabhängig gewichtet.
Historische Konsistenz: Waren die Signale eines Besuchers über mehrere Besuche hinweg stabil, steigt die Konfidenz. Schwanken die Signale häufig, sinkt die Konfidenz.
| Szenario | Typischer Wert | Erläuterung |
|---|---|---|
| Cookie-Treffer | 1.000 | UID des Cookies _vid_t serverseitig verifiziert |
| Erstbesuch | 0.900 | Keine vorherigen Datensätze zum Vergleich |
| Starke Fingerprint-Übereinstimmung | 0.990–0.999 | Alle Signale der Stufe 1 stimmen überein, die meisten der Stufe 2 |
| Teilweise Übereinstimmung (Browser-Update) | 0.950–0.989 | Stufe 1 stimmt überein, Stufe 2 geändert (neuer UA) |
| Schwache Übereinstimmung (wesentliche Änderungen) | 0.850–0.949 | Einige Signale der Stufe 1 haben sich geändert |
| Uneindeutig | 0.500–0.849 | Mehrere mögliche Übereinstimmungen in der Datenbank |
TRACIO verwendet ein First-Party-Cookie (_vid_t), um die Besucheridentität über Sitzungen hinweg aufrechtzuerhalten:
_vid_tSameSite=Lax und Secure bei HTTPS (nicht HttpOnly – der Agent liest es clientseitig)Das Cookie wird sowohl serverseitig (über den Antwort-Header Set-Cookie) als auch clientseitig vom Agent ausgestellt, und die UID wird zusätzlich als Fallback in localStorage gespiegelt, falls Cookies blockiert sind.
Der Server versucht, das Cookie auf zunehmend breiteren Domain-Bereichen zu setzen:
app.example.com → example.com → comVerwendet wird die breiteste Domain, auf der sich das Cookie erfolgreich setzen lässt. So bleibt das Cookie über Subdomains hinweg erhalten.
TRACIO kann dieselbe Person über verschiedene Browser auf demselben Gerät identifizieren, wenn die Signale der Stufe 1 übereinstimmende Hashes erzeugen. Da Stufe 1 auf Hardware- und Rendering-Merkmalen beruht (Canvas, WebGL, Audio, Schriftarten), sind diese Signale bei Chromium-basierten Browsern auf derselben Maschine oft identisch und verlieren an Übereinstimmung über verschiedene Engines hinweg (Chromium vs. Firefox vs. Safari). Die Zuordnung eines Desktop-Besuchers zu einem Mobil-Besucher ist nicht zu erwarten – die Hardware- und Rendering-Oberflächen unterscheiden sich.
Browserübergreifendes Matching ist von Natur aus eine Operation mit geringerer Konfidenz und wird in der Bewertung entsprechend behandelt.