Cara Kerjanya

TRACIO adalah sistem identifikasi client-server. Klien mengumpulkan sinyal browser dan mengirimkannya ke server, yang menghitung identifikator pengunjung yang stabil, menjalankan algoritma deteksi, dan mengembalikan hasil yang telah diperkaya. Bagian ini menjelaskan setiap tahap dari pipeline.

Gambaran Umum Arsitektur

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)

Tahap 1: Pengumpulan Sinyal

Ketika tracio.getResult() dipanggil, klien mengumpulkan 300+ sinyal browser berbeda yang diorganisasi ke dalam beberapa tier. Pengumpulan menggunakan pipeline multi-fase dengan Web Worker dan iframe bersama untuk performa.

Kategori Sinyal

Agen ini membawa 300+ sinyal dalam 15 kategori:

Canvas mencakup WebGL dan WebGPU selain rendering 2D; Tamper menjadi kategori terbesar karena mengenali lingkungan yang telah dimodifikasi menuntut lebih banyak pemeriksaan daripada sekadar membaca lingkungan yang utuh.

Pipeline Pengumpulan

Pipeline pengumpulan berjalan dalam empat tahap untuk meminimalkan pemblokiran main thread:

1. Tahap 1 (Immediate): Sinyal prioritas tinggi yang cepat dikumpulkan (properti navigator, layar, zona waktu). TURN probe juga dimulai di sini karena berjalan secara bersamaan.

2. Tahap 2 (Idle Callback): Sinyal sinkron yang diuntungkan oleh periode idle (CSS media query, storage probe, tes cookie).

3. Tahap 3 (Async): Sinyal yang memerlukan API asinkron atau rendering (canvas, WebGL, audio fingerprint, deteksi font, rendering emoji).

4. Web Worker: Pengumpulan sinyal terisolasi dalam thread khusus (deteksi fitur WASM, doNotTrack).

Sebuah iframe tersembunyi bersama dibuat sekali dan digunakan kembali oleh beberapa collector (emoji, MathML, warna sistem, font, screen frame) untuk menghindari overhead pembuatan iframe terpisah per sinyal.

Format Sinyal

Setiap sinyal mengikuti struktur yang konsisten:

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

Status code:

Tahap 2: Transport Terenkripsi

Sinyal yang dikumpulkan diserialisasi ke JSON, lalu dienkripsi dan dikompresi sebelum transmisi:

1. Serialisasi JSON: Semua nilai sinyal dikemas ke dalam objek JSON yang dikunci berdasarkan sinyal, ditambah field metadata (c untuk API key, t untuk tag, lid untuk linked ID).

2. Kompresi: Jika payload melebihi 1024 byte, payload dikompresi menggunakan CompressionStream("deflate-raw").

3. Enkripsi XOR: Payload dibungkus dalam envelope enkripsi:

   • Satu byte kunci XOR acak
   • Byte header (penanda validasi)
   • Padding acak (0-3 byte)
   • Sebuah mask XOR 9-byte
   • Payload yang di-XOR dengan mask yang berulang

4. Encoding Base64: Payload terenkripsi di-encode dengan Base64url dan dikirim sebagai body POST.

Permintaan dikirim ke ingress endpoint dengan query parameter untuk versi klien dan API key. Credential CORS disertakan untuk mengirim cookie first-party.

Tahap 3: Pemrosesan di Sisi Server

Server menerima payload terenkripsi dan memprosesnya melalui beberapa subsistem:

Ekstraksi Sinyal

Server men-decode envelope XOR, mendekompresi jika diperlukan, dan mem-parse data sinyal JSON. Status code dan nilai dari setiap sinyal diekstrak dan divalidasi.

Komputasi Visitor ID

Visitor ID dihitung menggunakan pendekatan 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

Setiap tier mengekstrak sinyal yang ditugaskan padanya, membangun string kanonik, dan meng-hash-nya dengan MurmurHash3-x64-128. Ketiga hash tier digabungkan dan di-encode dalam base62 untuk menghasilkan visitor ID final.

Penilaian Confidence

Skor confidence (0.0 hingga 1.0) menunjukkan seberapa yakin sistem bahwa pengunjung ini telah teridentifikasi dengan benar:

• Cocok cookie (1.0): Jika cookie _vid_t cocok dengan pengunjung yang sudah dikenal, confidence bernilai maksimal.
• Kunjungan pertama (0.90): Pengunjung baru tanpa catatan sebelumnya dimulai pada 0.90.
• Pengunjung yang kembali: Confidence dihitung dari pembobotan frekuensi sinyal (berbasis IDF) dan fuzzy matching terhadap fingerprint tersimpan menggunakan Hamming distance tingkat bit.

Deteksi Bot

Engine deteksi bot menjalankan beberapa detektor dan menggabungkan keluaran tertimbangnya menjadi skor bot; sinyal hard-fail dengan sendirinya menetapkan verdict bot. Nilai publik bot.score berada pada skala 0..100 dan verdict sampai kepada Anda sebagai bot.result. Ambang batas persisnya tidak dipublikasikan — ambang yang bisa dibaca adalah ambang yang bisa disiasati. Detektor yang berkontribusi meliputi:

1. Pemeriksaan flag webdriver (prioritas tertinggi)
2. Analisis sinyal otomasi komposit
3. Pencocokan UA good bot + verifikasi IP (reverse DNS)
4. Deteksi headless browser (11 penanda, ambang batas 2+)
5. Deteksi anomali panjang eval
6. Pencocokan pola UA bad bot
7. Klasifikasi framework otomasi (Puppeteer, Playwright, Cypress, Selenium)
8. Deteksi emulator (penilaian emulator seluler)
9. Deteksi DevTools
10. Klasifikasi privacy browser (Tor, Brave, Firefox ETP, Safari ITP)
11. Analisis perilaku (rate/entropi/interaksi)

Detektor instrumentasi (Frida), root/jailbreak, dan aplikasi kloning memang ada di platform, tetapi slot masukannya khusus native — agen browser tidak mengumpulkannya, sehingga keduanya tidak ikut menentukan verdict di web. Lihat Deteksi Bot untuk apa saja yang sepenuhnya aktif di web.

Pengayaan Smart Signal

Sinyal pengayaan di sisi server dihitung dari data sinyal mentah dan IP intelligence. Ini mencakup deteksi VPN/proxy/Tor, geolokasi IP, analisis tampering browser, dan penilaian suspect.

IP Intelligence

Subsistem IP intelligence menyediakan:

• VPN / Proxy / Tor / Datacenter: diklasifikasikan dari IP yang terhubung menggunakan basis data IP intelligence komersial (IP2Location)
• Geolokasi: akurasi tingkat kota dan ASN melalui MaxMind GeoIP2

Tahap 4: Respons

Server mengembalikan respons JSON yang berisi:

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

Ini adalah hasil yang di-resolve oleh tracio.getResult() di browser. Event lengkap yang telah diperkaya — termasuk bot_result kanonik (human / bot / uncertain), geolokasi, dan smart signal — dikirim di sisi server melalui webhook, dapat dibaca lewat Data API, dan ditampilkan di dashboard.

Klien menyimpan token pengunjung baik dalam cookie first-party (masa berlaku 365 hari, SameSite=Lax) maupun localStorage untuk persistensi lintas sesi.

Ringkasan Alur Data

Total round-trip: hitungan milidetik. Porsi terbesarnya adalah pengumpulan sinyal — perjalanan jaringan dan pekerjaan di sisi server adalah bagian yang lebih kecil — dan lamanya bergantung pada perangkat serta koneksi pengunjung. Tidak ada satu pun dari ini yang memblokir rendering halaman: agen dimuat secara asinkron dan setiap pemeriksaan yang berpotensi lambat dibatasi oleh timeout-nya sendiri.