Hoe het werkt

TRACIO is een client-server-identificatiesysteem. De client verzamelt browsersignalen en stuurt ze naar de server, die een stabiele bezoekersidentificator berekent, detectiealgoritmen uitvoert en verrijkte resultaten teruggeeft. In dit hoofdstuk wordt elke fase van de pipeline uitgelegd.

Architectuuroverzicht

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)

Fase 1: Signaalverzameling

Wanneer tracio.getResult() wordt aangeroepen, verzamelt de client 130+ verschillende browsersignalen die in tiers zijn georganiseerd. De verzameling gebruikt een meerfasige pipeline met Web Workers en gedeelde iframes voor de performance.

Signaalcategorieën

Verzamelingspipeline

De verzamelingspipeline draait in vier fasen om het blokkeren van de main thread te minimaliseren:

1. Fase 1 (Direct): Signalen met hoge prioriteit die snel te verzamelen zijn (navigator-eigenschappen, screen, tijdzone). De TURN-probe start hier ook, aangezien deze gelijktijdig wordt uitgevoerd.

2. Fase 2 (Idle Callback): Synchrone signalen die profiteren van een inactieve periode (CSS-media-queries, storage-probes, cookie-tests).

3. Fase 3 (Async): Signalen die asynchrone API's of rendering vereisen (canvas, WebGL, audio-fingerprint, fontdetectie, emoji-rendering).

4. Web Worker: Geïsoleerde signaalverzameling in een dedicated thread (WASM-featuredetectie, doNotTrack).

Er wordt eenmalig een gedeeld verborgen iframe aangemaakt dat door meerdere collectors wordt hergebruikt (emoji, MathML, systeemkleuren, fonts, screen-frame), om de overhead van het aanmaken van aparte iframes per signaal te vermijden.

Signaalformaat

Elk signaal volgt een consistente structuur:

interface Signal<T> {
  s: number // Status code
  v: T // Value (when successful)
}

Statuscodes:

Fase 2: Versleuteld transport

Verzamelde signalen worden geserialiseerd naar JSON en vervolgens vóór verzending versleuteld en gecomprimeerd:

1. JSON-serialisatie: Alle signaalwaarden worden verpakt in een JSON-object, gesleuteld per signaal, plus metadatavelden (c voor API-sleutel, t voor tag, lid voor linked ID).

2. Compressie: Als de payload groter is dan 1024 bytes, wordt deze gecomprimeerd met CompressionStream("deflate-raw").

3. XOR-versleuteling: De payload wordt in een versleutelingsenvelop verpakt:

   • Een willekeurige XOR-key-byte
   • Header-bytes (validatiemarkeringen)
   • Willekeurige padding (0-3 bytes)
   • Een 9-byte-XOR-masker
   • De payload ge-XOR'd met het herhalende masker

4. Base64-codering: De versleutelde payload wordt Base64url-gecodeerd en als POST-body verzonden.

Het verzoek wordt naar het ingress-endpoint gestuurd met query-parameters voor de client-versie en API-sleutel. CORS-credentials worden meegestuurd om first-party-cookies te verzenden.

Fase 3: Server-side verwerking

De server ontvangt de versleutelde payload en verwerkt deze via verschillende subsystemen:

Signaalextractie

De server decodeert de XOR-envelop, decomprimeert indien nodig en parseert de JSON-signaaldata. De statuscode en waarde van elk signaal worden geëxtraheerd en gevalideerd.

Berekening van bezoekers-ID

De bezoekers-ID wordt berekend met een tiered hashing-aanpak (V3):

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 identity

Elke tier extraheert zijn aangewezen signalen, bouwt een canonieke string op en hasht deze met MurmurHash3-x64-128. De drie tier-hashes worden aaneengeschakeld en in base62 gecodeerd om de uiteindelijke bezoekers-ID te produceren.

Confidence-scoring

De confidence-score (0.0 tot 1.0) geeft aan hoe zeker het systeem is dat deze bezoeker correct is geïdentificeerd:

• Cookie-match (1.0): Als de versleutelde _vid_t-cookie overeenkomt, is de confidence maximaal.
• Eerste bezoek (0.90): Nieuwe bezoekers zonder eerder record starten op 0.90.
• Terugkerende bezoeker: De confidence wordt berekend uit signaalfrequentie-weging (IDF-gebaseerd) en fuzzy matching tegen opgeslagen fingerprints met behulp van bit-niveau Hamming-afstand.

Bot Detection

De bot-detectie-engine voert meerdere detectoren uit waarvan de gewogen uitkomsten worden gecombineerd tot een bot-score (drempelwaarden: bot ≥ 0.70, suspicious ≥ 0.30; een hard-fail-signaal forceert een bot-verdict). Bijdragende detectoren zijn onder meer:

1. Webdriver-flag-controle (hoogste prioriteit)
2. Composite-automatiseringssignaalanalyse
3. Good-bot-UA-matching + IP-verificatie (reverse DNS)
4. Headless-browserdetectie (11 markers, drempel 2+)
5. Eval-length-anomaliedetectie
6. Bad-bot-UA-patroonmatching
7. Automatiseringsframework-classificatie (Puppeteer, Playwright, Cypress, Selenium)
8. VM-detectie (VMware, VirtualBox, Parallels, QEMU, Hyper-V)
9. Emulatordetectie (scoring voor mobiele emulators)
10. Frida-/instrumentatiedetectie
11. DevTools-detectie
12. Privacy-browserclassificatie (Tor, Brave, Firefox ETP, Safari ITP)
13. Detectie van gekloonde apps
14. Gedragsanalyse (rate/entropie/interactie)

Smart-signaalverrijking

Server-side verrijkingssignalen worden berekend uit de ruwe signaaldata en IP-intelligence. Deze omvatten VPN-/proxy-/Tor-detectie, IP-geolocatie, browser-tampering-analyse en suspect-scoring.

IP-intelligence

Het IP-intelligence-subsysteem levert:

• VPN / Proxy / Tor / Datacenter: geclassificeerd op basis van het verbindende IP-adres met behulp van commerciële IP-intelligence-databases (IP2Location)
• Geolocatie: nauwkeurigheid op stadsniveau en ASN via MaxMind GeoIP2

Fase 4: Antwoord

De server retourneert een JSON-antwoord met daarin:

{
  "visitorId": "X7fh2Hg9LkMn3pQr",
  "bot": {
    "detected": false,
    "confidence": 2,
    "reasons": []
  }
}

Dit is het resultaat waartoe tracio.getResult() in de browser wordt geresolved. Het volledige, verrijkte event — inclusief de canonieke bot_result (human / bot / uncertain), geolocatie en smart signals — wordt server-side geleverd via webhooks en getoond in het dashboard.

De client slaat een bezoekers-token op in zowel een first-party-cookie (365 dagen geldig, SameSite=Lax) als localStorage voor persistentie over sessies heen.

Samenvatting van de dataflow

Totale round-trip: Doorgaans 80-300ms, afhankelijk van netwerkomstandigheden en browsermogelijkheden.