How It Works

TRACIO är ett identifieringssystem av klient-server-typ. Klienten samlar in webbläsarsignaler och skickar dem till servern, som beräknar en stabil besökaridentifierare, kör detekteringsalgoritmer och returnerar berikade resultat. Det här avsnittet förklarar varje steg i pipelinen.

Arkitekturöversikt

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)

Steg 1: Signalinsamling

När tracio.getResult() anropas samlar klienten in 130+ olika webbläsarsignaler organiserade i nivåer (tiers). Insamlingen använder en flerfasig pipeline med Web Workers och delade iframes för prestandan.

Signalkategorier

Insamlings-pipeline

Insamlings-pipelinen körs i fyra steg för att minimera blockering av huvudtråden:

1. Steg 1 (Omedelbart): Högprioriterade signaler som är snabba att samla in (navigator-egenskaper, skärm, tidszon). TURN-proben startar också här eftersom den körs samtidigt.

2. Steg 2 (Idle Callback): Synkrona signaler som drar nytta av en inaktiv period (CSS media queries, storage-probes, cookie-tester).

3. Steg 3 (Async): Signaler som kräver asynkrona API:er eller rendering (canvas, WebGL, audio-fingeravtryck, typsnittsdetektering, emoji-rendering).

4. Web Worker: Isolerad signalinsamling i en dedikerad tråd (WASM-funktionsdetektering, doNotTrack).

En delad, dold iframe skapas en gång och återanvänds av flera collectors (emoji, MathML, systemfärger, typsnitt, skärmram) för att undvika omkostnaden med att skapa separata iframes per signal.

Signalformat

Varje signal följer en enhetlig struktur:

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

Statuskoder:

Steg 2: Krypterad transport

Insamlade signaler serialiseras till JSON och krypteras sedan och komprimeras före överföring:

1. JSON-serialisering: Alla signalvärden packas in i ett JSON-objekt nycklat per signal, plus metadatafält (c för API-nyckel, t för tagg, lid för länkat ID).

2. Komprimering: Om nyttolasten överstiger 1024 byte komprimeras den med CompressionStream("deflate-raw").

3. XOR-kryptering: Nyttolasten lindas in i ett krypteringskuvert:

   • En slumpmässig XOR-nyckelbyte
   • Header-byte (valideringsmarkörer)
   • Slumpmässig padding (0–3 byte)
   • En 9-byte XOR-mask
   • Nyttolasten XOR:ad med den upprepade masken

4. Base64-kodning: Den krypterade nyttolasten Base64url-kodas och skickas som POST-body.

Begäran skickas till ingress-endpointen med query-parametrar för klientversion och API-nyckel. CORS-credentials inkluderas för att skicka first-party-cookies.

Steg 3: Bearbetning på serversidan

Servern tar emot den krypterade nyttolasten och bearbetar den genom flera delsystem:

Signalextrahering

Servern avkodar XOR-kuvertet, dekomprimerar vid behov och parsar JSON-signaldatan. Varje signals statuskod och värde extraheras och valideras.

Beräkning av besökar-ID

Besökar-ID:t beräknas med en metod för tiered hashing (nivåindelad hashning) (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

Varje nivå extraherar sina tilldelade signaler, bygger en kanonisk sträng och hashar den med MurmurHash3-x64-128. De tre nivåhasharna sammanfogas och kodas i base62 för att producera det slutliga besökar-ID:t.

Konfidens-scoring

Konfidensvärdet (0.0 till 1.0) anger hur säkert systemet är på att den här besökaren har identifierats korrekt:

• Cookie-matchning (1.0): Om den krypterade _vid_t-cookien matchar är konfidensen maximal.
• Första besöket (0.90): Nya besökare utan tidigare registrering startar på 0.90.
• Återkommande besökare: Konfidensen beräknas från signalfrekvensviktning (IDF-baserad) och fuzzy-matchning mot lagrade fingeravtryck med bitnivå-Hamming-avstånd.

Bot Detection

Bot-detekteringsmotorn kör flera detektorer vars viktade utdata kombineras till ett bot-score (tröskelvärden: bot ≥ 0.70, suspicious ≥ 0.30; en hard-fail-signal tvingar fram ett bot-utfall). Bland de bidragande detektorerna finns:

1. Kontroll av webdriver-flagga (högsta prioritet)
2. Sammansatt analys av automatiseringssignaler
3. Matchning av UA för goda bottar + IP-verifiering (reverse DNS)
4. Detektering av headless-webbläsare (11 markörer, tröskelvärde 2+)
5. Detektering av anomali i eval-length
6. Mönstermatchning av UA för dåliga bottar
7. Klassificering av automatiserings-frameworks (Puppeteer, Playwright, Cypress, Selenium)
8. VM-detektering (VMware, VirtualBox, Parallels, QEMU, Hyper-V)
9. Emulatordetektering (scoring för mobilemulatorer)
10. Frida-/instrumenteringsdetektering
11. DevTools-detektering
12. Klassificering av integritetswebbläsare (Tor, Brave, Firefox ETP, Safari ITP)
13. Detektering av klonade appar
14. Beteendeanalys (rate/entropi/interaktion)

Berikning med smart signals

Berikningssignaler på serversidan beräknas från de råa signaldata och IP intelligence. Dessa inkluderar VPN-/proxy-/Tor-detektering, IP-geolokalisering, analys av webbläsarmanipulering och suspect-scoring.

IP Intelligence

Delsystemet för IP intelligence tillhandahåller:

• VPN / Proxy / Tor / Datacenter: klassificeras utifrån den anslutande IP-adressen med hjälp av kommersiella IP intelligence-databaser (IP2Location)
• Geolokalisering: noggrannhet på stadsnivå och ASN via MaxMind GeoIP2

Steg 4: Svar

Servern returnerar ett JSON-svar som innehåller:

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

Detta är resultatet som tracio.getResult() returnerar i webbläsaren. Den fullständiga, berikade händelsen — inklusive det kanoniska bot_result (human / bot / uncertain), geolokalisering och smart signals — levereras på serversidan via webhooks och visas i dashboarden.

Klienten lagrar en besökartoken både i en first-party-cookie (365 dagars giltighet, SameSite=Lax) och i localStorage för persistens över sessioner.

Sammanfattning av dataflödet

Total round-trip: Vanligtvis 80-300ms beroende på nätverksförhållanden och webbläsarens kapacitet.