How It Works

TRACIO เป็นระบบระบุตัวตนแบบ client-server ไคลเอนต์จะเก็บสัญญาณของเบราว์เซอร์แล้วส่งไปยังเซิร์ฟเวอร์ ซึ่งจะคำนวณตัวระบุผู้เยี่ยมชมที่เสถียร รันอัลกอริทึมการตรวจจับ และส่งผลลัพธ์ที่ถูกเสริมข้อมูลกลับมา ส่วนนี้จะอธิบายแต่ละขั้นตอนของ pipeline

ภาพรวมสถาปัตยกรรม

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 สัญญาณ ซึ่งจัดระเบียบไว้เป็น tier การเก็บใช้ pipeline แบบหลายเฟสร่วมกับ Web Worker และ iframe ที่ใช้ร่วมกันเพื่อประสิทธิภาพ

หมวดหมู่ของสัญญาณ

Pipeline การเก็บสัญญาณ

Pipeline การเก็บสัญญาณทำงานเป็นสี่ขั้นตอนเพื่อลดการบล็อก main thread ให้น้อยที่สุด:

1. ขั้นตอนที่ 1 (Immediate): สัญญาณที่มีความสำคัญสูงและเก็บได้รวดเร็ว (คุณสมบัติของ navigator, screen, timezone) TURN probe ก็เริ่มทำงานที่นี่เช่นกันเพราะรันแบบคู่ขนาน

2. ขั้นตอนที่ 2 (Idle Callback): สัญญาณแบบ synchronous ที่ได้ประโยชน์จากช่วงที่ว่าง (CSS media query, storage probe, cookie test)

3. ขั้นตอนที่ 3 (Async): สัญญาณที่ต้องใช้ API แบบ asynchronous หรือการเรนเดอร์ (canvas, WebGL, audio fingerprint, การตรวจจับฟอนต์, emoji rendering)

4. Web Worker: การเก็บสัญญาณแบบแยกอิสระใน thread เฉพาะ (การตรวจจับฟีเจอร์ WASM, doNotTrack)

iframe ที่ซ่อนไว้และใช้ร่วมกันจะถูกสร้างขึ้นเพียงครั้งเดียวและนำกลับมาใช้ซ้ำโดย collector หลายตัว (emoji, MathML, สีของระบบ, ฟอนต์, screen frame) เพื่อหลีกเลี่ยง overhead ของการสร้าง iframe แยกต่อสัญญาณ

รูปแบบของสัญญาณ

สัญญาณทุกตัวมีโครงสร้างที่สอดคล้องกัน:

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

Status code:

ขั้นตอนที่ 2: การส่งข้อมูลแบบเข้ารหัส

สัญญาณที่เก็บได้จะถูก serialize เป็น JSON จากนั้นเข้ารหัสและบีบอัดก่อนการส่ง:

1. JSON serialization: ค่าของสัญญาณทั้งหมดจะถูกแพ็กลงในออบเจ็กต์ JSON โดยใช้สัญญาณเป็น key พร้อมกับฟิลด์ metadata (c สำหรับ API key, t สำหรับ tag, lid สำหรับ linked ID)

2. การบีบอัด: หาก payload มีขนาดเกิน 1024 ไบต์ จะถูกบีบอัดด้วย CompressionStream("deflate-raw")

3. XOR Encryption: payload จะถูกห่อหุ้มไว้ในซองการเข้ารหัส:

   • ไบต์ XOR key แบบสุ่ม
   • Header byte (validation marker)
   • Padding แบบสุ่ม (0-3 ไบต์)
   • XOR mask ขนาด 9 ไบต์
   • payload ที่ถูก XOR กับ mask ที่วนซ้ำ

4. Base64 encoding: payload ที่เข้ารหัสแล้วจะถูกเข้ารหัสแบบ Base64url และส่งเป็น POST body

คำขอจะถูกส่งไปยัง ingress endpoint พร้อม query parameter สำหรับเวอร์ชันของไคลเอนต์และ API key โดยมีการรวม CORS credentials ไว้ด้วยเพื่อส่ง first-party cookie

ขั้นตอนที่ 3: การประมวลผลฝั่งเซิร์ฟเวอร์

เซิร์ฟเวอร์รับ payload ที่เข้ารหัสไว้และประมวลผลผ่านหลาย subsystem:

การสกัดสัญญาณ

เซิร์ฟเวอร์ถอดรหัสซอง XOR คลายการบีบอัดเมื่อจำเป็น และ parse ข้อมูลสัญญาณ JSON status code และค่าของสัญญาณแต่ละตัวจะถูกสกัดออกมาและตรวจสอบความถูกต้อง

การคำนวณ Visitor ID

Visitor ID คำนวณโดยใช้แนวทาง 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

แต่ละ tier จะสกัดสัญญาณที่กำหนดไว้ สร้าง string แบบ canonical แล้ว hash ด้วย MurmurHash3-x64-128 hash ของทั้งสาม tier จะถูกนำมาต่อกันและเข้ารหัสเป็น base62 เพื่อสร้าง visitor ID สุดท้าย

Confidence Scoring

Confidence score (0.0 ถึง 1.0) บ่งบอกว่าระบบมั่นใจแค่ไหนว่าผู้เยี่ยมชมรายนี้ถูกระบุตัวตนอย่างถูกต้อง:

• Cookie match (1.0): หากคุกกี้ _vid_t ที่เข้ารหัสไว้ตรงกัน ค่า confidence จะสูงสุด
• การเยี่ยมชมครั้งแรก (0.90): ผู้เยี่ยมชมใหม่ที่ยังไม่มีบันทึกก่อนหน้าจะเริ่มต้นที่ 0.90
• ผู้เยี่ยมชมที่กลับมาซ้ำ: ค่า confidence คำนวณจากการถ่วงน้ำหนักความถี่ของสัญญาณ (แบบ IDF) และการทำ fuzzy matching เทียบกับ fingerprint ที่จัดเก็บไว้โดยใช้ Hamming distance ระดับบิต

Bot Detection

เอนจิน bot detection รัน detector หลายตัวซึ่งผลลัพธ์แบบถ่วงน้ำหนักจะถูกรวมเข้าเป็น bot score (threshold: bot ≥ 0.70, suspicious ≥ 0.30; สัญญาณ hard-fail จะบังคับให้ผลตัดสินเป็น bot) detector ที่มีส่วนร่วมได้แก่:

1. การตรวจสอบ Webdriver flag (ความสำคัญสูงสุด)
2. การวิเคราะห์สัญญาณ automation แบบ composite
3. การจับคู่ UA ของ good bot + การยืนยัน IP (reverse DNS)
4. การตรวจจับเบราว์เซอร์แบบ headless (11 marker, threshold 2+)
5. การตรวจจับความผิดปกติของ eval length
6. การจับคู่รูปแบบ UA ของ bad bot
7. การจำแนก automation framework (Puppeteer, Playwright, Cypress, Selenium)
8. การตรวจจับ VM (VMware, VirtualBox, Parallels, QEMU, Hyper-V)
9. การตรวจจับ emulator (การให้คะแนน emulator บนมือถือ)
10. การตรวจจับ Frida/instrumentation
11. การตรวจจับ DevTools
12. การจำแนกเบราว์เซอร์ที่เน้นความเป็นส่วนตัว (Tor, Brave, Firefox ETP, Safari ITP)
13. การตรวจจับแอปที่ถูกโคลน
14. การวิเคราะห์พฤติกรรม (rate/entropy/interaction)

Smart Signal Enrichment

สัญญาณเสริมข้อมูลฝั่งเซิร์ฟเวอร์คำนวณจากข้อมูลสัญญาณดิบและ IP intelligence ซึ่งรวมถึงการตรวจจับ VPN/proxy/Tor, การระบุตำแหน่งทางภูมิศาสตร์ของ IP, การวิเคราะห์การดัดแปลงเบราว์เซอร์ และ suspect scoring

IP Intelligence

Subsystem IP intelligence ให้บริการ:

• VPN / Proxy / Tor / Datacenter: จำแนกจาก IP ที่เชื่อมต่อโดยใช้ฐานข้อมูล IP intelligence เชิงพาณิชย์ (IP2Location)
• Geolocation: ความแม่นยำระดับเมืองและ ASN ผ่าน MaxMind GeoIP2

ขั้นตอนที่ 4: การตอบกลับ

เซิร์ฟเวอร์ส่ง JSON response กลับมาโดยมีเนื้อหา:

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

นี่คือผลลัพธ์ที่ tracio.getResult() resolve ออกมาในเบราว์เซอร์ ส่วน event ฉบับเต็มที่ถูกเสริมข้อมูล — รวมถึง bot_result แบบ canonical (human / bot / uncertain), geolocation และ smart signal — จะถูก ส่งฝั่งเซิร์ฟเวอร์ผ่าน webhook และแสดงใน dashboard

ไคลเอนต์จัดเก็บ visitor token ทั้งใน first-party cookie (หมดอายุ 365 วัน, SameSite=Lax) และใน localStorage เพื่อความคงอยู่ข้ามเซสชัน

สรุป Data Flow

Round-trip ทั้งหมด: โดยทั่วไป 80-300ms ขึ้นอยู่กับสภาพเครือข่ายและความสามารถของเบราว์เซอร์