TRACIO ist ein Client-Server-Identifizierungssystem. Der Client erfasst Browser-Signale und sendet sie an den Server, der einen stabilen Besucher-Identifikator berechnet, Erkennungsalgorithmen ausführt und angereicherte Ergebnisse zurückgibt. Dieser Abschnitt erläutert jede Stufe der Pipeline.
Browser TRACIO Cloud | | |-- Tracio.init({ publicKey }) ---------> | (init, no network) | | |-- tracio.getResult() ----------------> | | 1. Collect 130+ browser signals | | 2. Encrypt (XOR + deflate + B64) | | 3. POST to ingress endpoint | | | | |-- Decrypt & extract signals | |-- Compute visitor ID (MurmurHash3-128) | |-- Run bot detection (weighted scoring) | |-- Run smart signals (server-side enrichment) | |-- Run IP intelligence (VPN/proxy/Tor) | |-- Store visit event | | |<-- JSON response ------------------- | | visitorId, confidence, | | bot detection, smart signals | | | |-- Store visitor cookie (_vid_t) -----> | (365-day persistence)Wenn tracio.getResult() aufgerufen wird, erfasst der Client 130+ verschiedene Browser-Signale, die in Tiers organisiert sind. Die Erfassung nutzt eine mehrphasige Pipeline mit Web Workern und gemeinsam genutzten iframes für die Performance.
| Kategorie | Signalanzahl | Beispiele |
|---|---|---|
| Canvas & WebGL | 9 | Canvas-Fingerprint, WebGL-Renderer, WebGL-Parameter, WebGPU |
| Audio | 3 | AudioContext-Fingerprint, Base-Latenz, DRM-Timing |
| Schriftarten & Rendering | 10 | Schrifterkennung, Schrifteinstellungen, MathML, Emoji-Rendering |
| Navigator & Plattform | 25 | User-Agent, Sprachen, Screen, Hardware-Concurrency, Zeitzone |
| Storage & Cookies | 10 | localStorage, sessionStorage, Cookies, Storage-Quota |
| CSS & Media Queries | 10 | Farbschema, HDR, Reduced Motion, Forced Colors |
| Netzwerk & WebRTC | 3 | TURN-Probe, Verbindungs-RTT, App-Version |
| Bot Detection | 15 | Webdriver-Flag, Automatisierungs-Frameworks, Eval-Length |
| Tamper Detection | 8 | Property-Getter-Introspektion, Prototypenketten, Native-Function-Integrität |
| Custom Extensions | 14 | Math-Fingerprint, Architektur-Erkennung, WASM-Features |
Die Erfassungs-Pipeline läuft in vier Stufen, um das Blockieren des Main-Threads zu minimieren:
Stufe 1 (Sofort): Hochpriorisierte Signale, die schnell zu erfassen sind (Navigator-Eigenschaften, Screen, Zeitzone). Die TURN-Probe startet ebenfalls hier, da sie nebenläufig ausgeführt wird.
Stufe 2 (Idle Callback): Synchrone Signale, die von einer Leerlaufphase profitieren (CSS-Media-Queries, Storage-Probes, Cookie-Tests).
Stufe 3 (Async): Signale, die asynchrone APIs oder Rendering erfordern (Canvas, WebGL, Audio-Fingerprint, Schrifterkennung, Emoji-Rendering).
Web Worker: Isolierte Signalerfassung in einem dedizierten Thread (WASM-Feature-Erkennung, doNotTrack).
Ein gemeinsam genutzter versteckter iframe wird einmal erstellt und von mehreren Collectors wiederverwendet (Emoji, MathML, Systemfarben, Schriftarten, Screen-Frame), um den Overhead separater iframes pro Signal zu vermeiden.
Jedes Signal folgt einer einheitlichen Struktur:
interface Signal<T> { s: number // Status code v: T // Value (when successful)}Statuscodes:
| Code | Bedeutung |
|---|---|
0 | Erfolg |
-1 | Nicht verfügbar (Eigenschaft undefined) |
-2 | Sekundärprüfung fehlgeschlagen |
-3 | Unerwartetes Verhalten |
-4 | Timeout |
-5 | Deaktiviert |
-6 | Durch CSP blockiert |
-7 | Sicherheitsfehler |
Erfasste Signale werden zu JSON serialisiert, dann vor der Übertragung verschlüsselt und komprimiert:
JSON-Serialisierung: Alle Signalwerte werden in ein JSON-Objekt gepackt, nach Signal geschlüsselt, plus Metadatenfelder (c für API-Schlüssel, t für Tag, lid für Linked-ID).
Kompression: Überschreitet die Payload 1024 Bytes, wird sie mit CompressionStream("deflate-raw") komprimiert.
XOR-Verschlüsselung: Die Payload wird in einen Verschlüsselungsumschlag gewickelt:
Base64-Kodierung: Die verschlüsselte Payload wird Base64url-kodiert und als POST-Body gesendet.
Die Anfrage wird an den Ingress-Endpunkt mit Query-Parametern für Client-Version und API-Schlüssel gesendet. CORS-Credentials werden einbezogen, um First-Party-Cookies zu senden.
Der Server empfängt die verschlüsselte Payload und verarbeitet sie durch mehrere Subsysteme:
Der Server dekodiert den XOR-Umschlag, dekomprimiert bei Bedarf und parst die JSON-Signaldaten. Statuscode und Wert jedes Signals werden extrahiert und validiert.
Die Besucher-ID wird mit einem Tiered-Hashing-Ansatz (V3) berechnet:
Tier 1 (Frozen): 20 base62 characters - Stable hardware signals that rarely change - Canvas, WebGL renderer, audio fingerprint, fonts - Provides long-term visitor identity
Tier 2 (Semi-stable): 10 base62 characters - Signals that change with browser updates - User-Agent data, Client Hints, plugins - Extensible without breaking Tier 1
Tier 3 (Volatile): 10 base62 characters - Signals that change frequently - Screen resolution, timezone, language - Used for confidence scoring, not identityJeder Tier extrahiert seine zugewiesenen Signale, baut einen kanonischen String auf und hasht ihn mit MurmurHash3-x64-128. Die drei Tier-Hashes werden verkettet und in base62 kodiert, um die finale Besucher-ID zu erzeugen.
Der Konfidenzwert (0.0 bis 1.0) gibt an, wie sicher das System ist, dass dieser Besucher korrekt identifiziert wurde:
_vid_t-Cookie überein, ist die Konfidenz maximal.Die Bot-Erkennungs-Engine führt mehrere Detektoren aus, deren gewichtete Ausgaben zu einem Bot-Score kombiniert werden (Schwellenwerte: bot ≥ 0,70, suspicious ≥ 0,30; ein Hard-Fail-Signal erzwingt ein Bot-Verdikt). Zu den beitragenden Detektoren gehören:
Serverseitige Anreicherungssignale werden aus den Rohsignaldaten und der IP-Intelligence berechnet. Dazu gehören VPN-/Proxy-/Tor-Erkennung, IP-Geolokalisierung, Browser-Tampering-Analyse und Suspect-Scoring.
Das IP-Intelligence-Subsystem stellt bereit:
Der Server gibt eine JSON-Antwort zurück, die Folgendes enthält:
{ "visitorId": "X7fh2Hg9LkMn3pQr", "bot": { "detected": false, "confidence": 2, "reasons": [] }}Dies ist das Ergebnis, zu dem tracio.getResult() im Browser auflöst. Das
vollständige, angereicherte Ereignis — einschließlich des kanonischen bot_result
(human / bot / uncertain), der Geolokalisierung und der Smart Signals — wird
serverseitig über Webhooks zugestellt und im
Dashboard angezeigt.
Der Client speichert ein Besucher-Token sowohl in einem First-Party-Cookie (365 Tage Gültigkeit, SameSite=Lax) als auch in localStorage zur Persistenz über Sitzungen hinweg.
| Schritt | Ort | Dauer | Beschreibung |
|---|---|---|---|
| 1 | Browser | ~5ms | Agent initialisieren, gemeinsamen iframe erstellen |
| 2 | Browser | ~50-150ms | 130+ Signale erfassen (parallel, mehrphasig) |
| 3 | Browser | ~5ms | Payload verschlüsseln und komprimieren |
| 4 | Netzwerk | ~10-50ms | POST an den Server |
| 5 | Server | ~5-20ms | Entschlüsseln, Signale extrahieren, Besucher-ID berechnen |
| 6 | Server | ~5-15ms | Bot Detection und Smart Signals ausführen |
| 7 | Server | ~5ms | Antwort erstellen |
| 8 | Netzwerk | ~10-50ms | JSON-Antwort zurückgeben |
| 9 | Browser | ~1ms | Besucher-Cookie speichern |
Gesamter Round-Trip: Typischerweise 80-300ms, abhängig von Netzwerkbedingungen und Browser-Fähigkeiten.