How It Works

TRACIO to system identyfikacji typu klient–serwer. Klient zbiera sygnały przeglądarki i wysyła je do serwera, który oblicza stabilny identyfikator odwiedzającego, uruchamia algorytmy wykrywania i zwraca wzbogacone wyniki. Ta sekcja opisuje każdy etap potoku.

Przegląd architektury

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)

Etap 1: Zbieranie sygnałów

Gdy wywoływana jest funkcja tracio.getResult(), klient zbiera ponad 130 różnych sygnałów przeglądarki zorganizowanych w warstwy (tiers). Zbieranie wykorzystuje wielofazowy potok z Web Workerami i współdzielonymi ramkami iframe dla lepszej wydajności.

Kategorie sygnałów

Potok zbierania

Potok zbierania działa w czterech etapach, aby zminimalizować blokowanie głównego wątku:

1. Etap 1 (Natychmiastowy): Sygnały o wysokim priorytecie, które są szybkie do zebrania (właściwości navigatora, ekran, strefa czasowa). Tutaj startuje również TURN probe, ponieważ działa współbieżnie.

2. Etap 2 (Idle Callback): Sygnały synchroniczne, które korzystają z okresu bezczynności (CSS media queries, sondy storage, testy cookies).

3. Etap 3 (Async): Sygnały wymagające asynchronicznych API lub renderowania (canvas, WebGL, audio fingerprint, wykrywanie czcionek, renderowanie emoji).

4. Web Worker: Izolowane zbieranie sygnałów w dedykowanym wątku (wykrywanie funkcji WASM, doNotTrack).

Współdzielona ukryta ramka iframe jest tworzona raz i ponownie wykorzystywana przez wiele kolektorów (emoji, MathML, kolory systemowe, czcionki, ramka ekranu), aby uniknąć narzutu związanego z tworzeniem osobnych ramek iframe dla każdego sygnału.

Format sygnału

Każdy sygnał ma spójną strukturę:

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

Kody statusu:

Etap 2: Zaszyfrowany transport

Zebrane sygnały są serializowane do formatu JSON, a następnie szyfrowane i kompresowane przed transmisją:

1. Serializacja JSON: Wszystkie wartości sygnałów są pakowane do obiektu JSON kluczowanego według sygnału, wraz z polami metadanych (c dla klucza API, t dla tagu, lid dla linked ID).

2. Kompresja: Jeśli payload przekracza 1024 bajty, jest kompresowany za pomocą CompressionStream("deflate-raw").

3. Szyfrowanie XOR: Payload jest owijany w kopertę szyfrującą:

   • Losowy bajt klucza XOR
   • Bajty nagłówka (markery walidacji)
   • Losowy padding (0-3 bajty)
   • 9-bajtowa maska XOR
   • Payload poddany operacji XOR z powtarzającą się maską

4. Kodowanie Base64: Zaszyfrowany payload jest kodowany w Base64url i wysyłany jako treść żądania POST.

Żądanie jest wysyłane do endpointu ingress z parametrami zapytania określającymi wersję klienta i klucz API. Dołączane są poświadczenia CORS w celu przesłania cookies first-party.

Etap 3: Przetwarzanie po stronie serwera

Serwer odbiera zaszyfrowany payload i przetwarza go przez kilka podsystemów:

Ekstrakcja sygnałów

Serwer dekoduje kopertę XOR, w razie potrzeby dekompresuje i parsuje dane sygnałów JSON. Kod statusu i wartość każdego sygnału są wyodrębniane i walidowane.

Obliczanie identyfikatora odwiedzającego

Identyfikator odwiedzającego jest obliczany za pomocą podejścia tiered hashing (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

Każda warstwa wyodrębnia przypisane jej sygnały, buduje kanoniczny ciąg znaków i haszuje go za pomocą MurmurHash3-x64-128. Trzy hasze warstw są łączone i kodowane w base62, tworząc ostateczny identyfikator odwiedzającego.

Ocena pewności (confidence scoring)

Wynik pewności (confidence, od 0.0 do 1.0) wskazuje, jak bardzo system jest pewny, że dany odwiedzający został poprawnie zidentyfikowany:

• Dopasowanie cookie (1.0): Jeśli zaszyfrowane cookie _vid_t pasuje, pewność jest maksymalna.
• Pierwsza wizyta (0.90): Nowi odwiedzający bez wcześniejszego rekordu zaczynają od 0.90.
• Powracający odwiedzający: Pewność jest obliczana na podstawie ważenia częstości sygnałów (opartego na IDF) oraz rozmytego dopasowania (fuzzy matching) do zapisanych fingerprintów przy użyciu odległości Hamminga na poziomie bitów.

Bot Detection

Silnik wykrywania botów uruchamia wiele detektorów, których ważone wyniki są łączone w wynik bota (progi: bot ≥ 0,70, suspicious ≥ 0,30; sygnał typu hard-fail wymusza werdykt bota). Do współtworzących detektorów należą:

1. Sprawdzenie flagi webdriver (najwyższy priorytet)
2. Analiza złożonego sygnału automatyzacji
3. Dopasowanie UA dobrych botów + weryfikacja IP (reverse DNS)
4. Wykrywanie przeglądarek headless (11 markerów, próg 2+)
5. Wykrywanie anomalii eval length
6. Dopasowanie wzorców UA złych botów
7. Klasyfikacja frameworków automatyzacji (Puppeteer, Playwright, Cypress, Selenium)
8. Wykrywanie maszyn wirtualnych (VMware, VirtualBox, Parallels, QEMU, Hyper-V)
9. Wykrywanie emulatorów (scoring emulatorów mobilnych)
10. Wykrywanie Frida/instrumentacji
11. Wykrywanie DevTools
12. Klasyfikacja przeglądarek prywatności (Tor, Brave, Firefox ETP, Safari ITP)
13. Wykrywanie sklonowanych aplikacji
14. Analiza behawioralna (tempo/entropia/interakcja)

Wzbogacanie o smart signals

Sygnały wzbogacające po stronie serwera są obliczane na podstawie surowych danych sygnałów i IP intelligence. Obejmują one wykrywanie VPN/proxy/Tor, geolokalizację IP, analizę manipulacji przeglądarką oraz scoring podejrzliwości.

IP Intelligence

Podsystem IP intelligence dostarcza:

• VPN / Proxy / Tor / Datacenter: klasyfikowane na podstawie łączącego się IP przy użyciu komercyjnych baz danych IP intelligence (IP2Location)
• Geolokalizacja: dokładność na poziomie miasta oraz ASN dzięki MaxMind GeoIP2

Etap 4: Odpowiedź

Serwer zwraca odpowiedź JSON zawierającą:

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

To jest wynik, do którego rozwiązuje się tracio.getResult() w przeglądarce. Pełne, wzbogacone zdarzenie — w tym kanoniczny bot_result (human / bot / uncertain), geolokalizacja i smart signals — jest dostarczane po stronie serwera przez webhooks i prezentowane w dashboardzie.

Klient przechowuje token odwiedzającego zarówno w cookie first-party (ważność 365 dni, SameSite=Lax), jak i w localStorage w celu utrzymania trwałości między sesjami.

Podsumowanie przepływu danych

Całkowity round-trip: Zazwyczaj 80-300ms w zależności od warunków sieciowych i możliwości przeglądarki.