Как это работает

TRACIO — это клиент-серверная система идентификации. Клиент собирает сигналы браузера и отправляет их на сервер, который вычисляет стабильный идентификатор посетителя, запускает алгоритмы обнаружения и возвращает обогащённые результаты. В этом разделе описывается каждый этап конвейера.

Обзор архитектуры

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)

Этап 1: Сбор сигналов

Когда вызывается tracio.getResult(), клиент собирает 130+ различных сигналов браузера, организованных в уровни (tiers). Сбор использует многофазный конвейер с Web Workers и общими iframe для производительности.

Категории сигналов

Конвейер сбора

Конвейер сбора работает в четыре стадии, чтобы минимизировать блокировку основного потока:

1. Стадия 1 (Немедленно): Высокоприоритетные сигналы, которые собираются быстро (свойства navigator, экран, часовой пояс). TURN-проба также запускается здесь, так как выполняется параллельно.

2. Стадия 2 (Idle Callback): Синхронные сигналы, которые выигрывают от периода простоя (CSS-медиазапросы, пробы хранилища, тесты cookies).

3. Стадия 3 (Async): Сигналы, требующие асинхронных API или рендеринга (canvas, WebGL, audio-fingerprint, определение шрифтов, рендеринг emoji).

4. Web Worker: Изолированный сбор сигналов в выделенном потоке (определение возможностей WASM, doNotTrack).

Общий скрытый iframe создаётся один раз и повторно используется несколькими коллекторами (emoji, MathML, системные цвета, шрифты, кадр экрана), чтобы избежать накладных расходов на создание отдельных iframe для каждого сигнала.

Формат сигнала

Каждый сигнал имеет единообразную структуру:

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

Коды статуса:

Этап 2: Зашифрованная передача

Собранные сигналы сериализуются в JSON, затем шифруются и сжимаются перед передачей:

1. Сериализация в JSON: Все значения сигналов упаковываются в JSON-объект с ключами по сигналам, плюс поля метаданных (c для API-ключа, t для тега, lid для связанного ID).

2. Сжатие: Если payload превышает 1024 байта, он сжимается с помощью CompressionStream("deflate-raw").

3. XOR-шифрование: Payload оборачивается в шифровальный конверт:

   • Случайный байт XOR-ключа
   • Байты заголовка (маркеры валидации)
   • Случайное заполнение (0-3 байта)
   • 9-байтовая XOR-маска
   • Payload, объединённый по XOR с повторяющейся маской

4. Base64-кодирование: Зашифрованный payload кодируется в Base64url и отправляется в теле POST-запроса.

Запрос отправляется на ingress-эндпоинт с query-параметрами версии клиента и API-ключа. Учётные данные CORS включаются для отправки first-party cookies.

Этап 3: Обработка на стороне сервера

Сервер получает зашифрованный payload и обрабатывает его через несколько подсистем:

Извлечение сигналов

Сервер декодирует XOR-конверт, при необходимости распаковывает и парсит JSON-данные сигналов. Код статуса и значение каждого сигнала извлекаются и валидируются.

Вычисление ID посетителя

ID посетителя вычисляется с помощью подхода многоуровневого хеширования (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

Каждый уровень извлекает назначенные ему сигналы, строит канонизированную строку и хеширует её с помощью MurmurHash3-x64-128. Три хеша уровней конкатенируются и кодируются в base62, образуя финальный ID посетителя.

Оценка достоверности (confidence)

Оценка достоверности (от 0.0 до 1.0) показывает, насколько система уверена, что этот посетитель идентифицирован верно:

• Совпадение cookie (1.0): Если зашифрованный cookie _vid_t совпадает, достоверность максимальна.
• Первый визит (0.90): Новые посетители без предыдущей записи стартуют с 0.90.
• Вернувшийся посетитель: Достоверность вычисляется из взвешивания частоты сигналов (на основе IDF) и нечёткого сопоставления с сохранёнными fingerprint'ами через побитовое расстояние Хэмминга.

Обнаружение ботов

Движок обнаружения ботов запускает несколько детекторов, чьи взвешенные выходы объединяются в bot-score (пороги: bot ≥ 0.70, suspicious ≥ 0.30; сигнал жёсткого отказа принудительно выносит вердикт «бот»). В число участвующих детекторов входят:

1. Проверка флага webdriver (высший приоритет)
2. Анализ композитного сигнала автоматизации
3. Сопоставление UA хороших ботов + проверка IP (обратный DNS)
4. Обнаружение headless-браузера (11 маркеров, порог 2+)
5. Обнаружение аномалии длины eval
6. Сопоставление UA-паттернов вредоносных ботов
7. Классификация фреймворков автоматизации (Puppeteer, Playwright, Cypress, Selenium)
8. Обнаружение VM (VMware, VirtualBox, Parallels, QEMU, Hyper-V)
9. Обнаружение эмуляторов (скоринг мобильных эмуляторов)
10. Обнаружение Frida/инструментирования
11. Обнаружение DevTools
12. Классификация privacy-браузеров (Tor, Brave, Firefox ETP, Safari ITP)
13. Обнаружение клонированных приложений
14. Поведенческий анализ (частота/энтропия/взаимодействие)

Обогащение smart signals

Обогащающие сигналы на стороне сервера вычисляются из сырых данных сигналов и IP intelligence. Они включают обнаружение VPN/proxy/Tor, IP-геолокацию, анализ подмены браузера и скоринг подозрительности.

IP Intelligence

Подсистема IP intelligence предоставляет:

• VPN / Proxy / Tor / Datacenter: классификация по подключающемуся IP с помощью коммерческих баз IP intelligence (IP2Location)
• Геолокация: точность до уровня города и ASN через MaxMind GeoIP2

Этап 4: Ответ

Сервер возвращает JSON-ответ, содержащий:

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

Это результат, к которому разрешается tracio.getResult() в браузере. Полное, обогащённое событие — включая канонический bot_result (human / bot / uncertain), геолокацию и smart signals — доставляется на стороне сервера через webhooks и отображается в дашборде.

Клиент сохраняет токен посетителя как в first-party cookie (срок действия 365 дней, SameSite=Lax), так и в localStorage для персистентности между сессиями.

Сводка потока данных

Полный round-trip: Обычно 80-300ms в зависимости от условий сети и возможностей браузера.