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.
Browser TRACIO Cloud | | |-- Tracio.init({ publicKey }) ---------> | (init, no network) | | |-- tracio.getResult() ----------------> | | 1. Collect 300+ 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)Gdy wywoływana jest funkcja tracio.getResult(), klient zbiera ponad 300 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.
Agent dostarcza 300+ sygnałów w 15 kategoriach:
| Kategoria | Sygnałów | Kategoria | Sygnałów |
|---|---|---|---|
| Tamper | 82 | Fonts | 15 |
| Navigator | 72 | Network | 15 |
| Bot | 32 | Persistence | 14 |
| Canvas | 26 | Intl | 13 |
| CSS | 19 | Audio | 12 |
| Privacy | 17 | Storage | 12 |
| Crypto | 16 | Behavioral | 5 |
| Display | 15 |
Canvas obejmuje WebGL i WebGPU na równi z renderowaniem 2D; Tamper jest największą kategorią, ponieważ rozpoznanie zmodyfikowanego środowiska wymaga więcej prób niż odczytanie niezmodyfikowanego.
Potok zbierania działa w czterech etapach, aby zminimalizować blokowanie głównego wątku:
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.
Etap 2 (Idle Callback): Sygnały synchroniczne, które korzystają z okresu bezczynności (CSS media queries, sondy storage, testy cookies).
Etap 3 (Async): Sygnały wymagające asynchronicznych API lub renderowania (canvas, WebGL, audio fingerprint, wykrywanie czcionek, renderowanie emoji).
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.
Każdy sygnał ma spójną strukturę:
interface Signal<T> { s: number // Status code v: T // Value (when successful)}Kody statusu:
| Code | Znaczenie |
|---|---|
0 | Sukces |
-1 | Niedostępne (właściwość undefined) |
-2 | Sprawdzenie dodatkowe nieudane |
-3 | Nieoczekiwane zachowanie |
-4 | Timeout |
-5 | Wyłączone |
-6 | Zablokowane przez CSP |
-7 | Błąd bezpieczeństwa |
Zebrane sygnały są serializowane do formatu JSON, a następnie szyfrowane i kompresowane przed transmisją:
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).
Kompresja: Jeśli payload przekracza 1024 bajty, jest kompresowany za pomocą CompressionStream("deflate-raw").
Szyfrowanie XOR: Payload jest owijany w kopertę szyfrującą:
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.
Serwer odbiera zaszyfrowany payload i przetwarza go przez kilka podsystemó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.
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 identityKaż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.
Wynik pewności (confidence, od 0.0 do 1.0) wskazuje, jak bardzo system jest pewny, że dany odwiedzający został poprawnie zidentyfikowany:
_vid_t pasuje do znanego odwiedzającego, pewność jest maksymalna.Silnik wykrywania botów uruchamia wiele detektorów i sumuje ich ważone wyniki w wynik bota; sygnał typu hard-fail samodzielnie przesądza o werdykcie bota. Publiczna wartość bot.score to skala 0..100, a werdykt trafia do Ciebie jako bot.result. Dokładne progi nie są publikowane: próg, który można odczytać, to próg, pod który można się dostroić. Do współtworzących detektorów należą:
Detektory instrumentacji (Frida), roota/jailbreaku i sklonowanych aplikacji istnieją w platformie, ale ich sloty wejściowe są wyłącznie natywne — agent przeglądarkowy ich nie zbiera, więc nie wpływają na werdykt w webie. To, co w webie działa w pełni, opisuje Wykrywanie botów.
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.
Podsystem IP intelligence dostarcza:
Serwer zwraca odpowiedź JSON zawierającą:
{ "visitorId": "X7fh2Hg9LkMn3pQr5tBvQw3xZa9mK2pL4nR8dT6y", "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, odczytywane przez
Data API 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.
| Krok | Lokalizacja | Opis |
|---|---|---|
| 1 | Przeglądarka | Inicjalizacja agenta, utworzenie współdzielonej ramki iframe |
| 2 | Przeglądarka | Zebranie 300+ sygnałów (równolegle, wielofazowo) |
| 3 | Przeglądarka | Zaszyfrowanie i skompresowanie payloadu |
| 4 | Sieć | POST do serwera |
| 5 | Serwer | Odszyfrowanie, ekstrakcja sygnałów, obliczenie visitor ID |
| 6 | Serwer | Uruchomienie bot detection i smart signals |
| 7 | Serwer | Zbudowanie odpowiedzi |
| 8 | Sieć | Zwrócenie odpowiedzi JSON |
| 9 | Przeglądarka | Zapisanie cookie odwiedzającego |
Całkowity round-trip: milisekundy. Największą część zajmuje zbieranie sygnałów — przeskoki sieciowe i praca po stronie serwera są mniejsze — a czas zależy od urządzenia i połączenia odwiedzającego. Nic z tego nie blokuje renderowania strony: agent ładuje się asynchronicznie, a każde sprawdzenie, które może potrwać, jest ograniczone własnym timeoutem.