작동 방식

TRACIO는 클라이언트-서버 식별 시스템입니다. 클라이언트는 브라우저 신호를 수집하여 서버로 전송하고, 서버는 안정적인 방문자 식별자를 계산하고, 탐지 알고리즘을 실행하며, 보강된 결과를 반환합니다. 이 섹션에서는 파이프라인의 각 단계를 설명합니다.

아키텍처 개요

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)

1단계: 신호 수집

tracio.getResult()가 호출되면 클라이언트는 계층(tier)으로 구성된 300개 이상의 개별 브라우저 신호를 수집합니다. 수집은 성능을 위해 Web Worker와 공유 iframe을 사용하는 다단계 파이프라인을 이용합니다.

신호 카테고리

에이전트는 15개 카테고리에 걸쳐 300개 이상의 신호를 제공합니다:

Canvas는 2D 렌더링뿐 아니라 WebGL과 WebGPU도 포함합니다. Tamper가 가장 큰 카테고리인 이유는, 변조된 환경을 알아보는 데에는 손대지 않은 환경을 읽는 것보다 더 많은 프로브가 필요하기 때문입니다.

수집 파이프라인

수집 파이프라인은 메인 스레드 차단을 최소화하기 위해 네 단계로 실행됩니다:

1. 1단계(즉시): 수집이 빠른 고우선순위 신호(navigator 속성, 화면, 시간대). TURN 프로브는 동시에 실행되므로 여기서 함께 시작됩니다.

2. 2단계(Idle Callback): 유휴 시간의 이점을 얻는 동기 신호(CSS 미디어 쿼리, 스토리지 프로브, 쿠키 테스트).

3. 3단계(비동기): 비동기 API 또는 렌더링이 필요한 신호(canvas, WebGL, 오디오 지문, 글꼴 탐지, 이모지 렌더링).

4. Web Worker: 전용 스레드에서의 격리된 신호 수집(WASM 기능 탐지, doNotTrack).

공유된 숨김 iframe은 한 번만 생성되어 여러 수집기(이모지, MathML, 시스템 색상, 글꼴, 화면 프레임)에서 재사용되며, 이를 통해 신호마다 별도의 iframe을 생성하는 오버헤드를 방지합니다.

신호 형식

모든 신호는 일관된 구조를 따릅니다:

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

상태 코드:

2단계: 암호화된 전송

수집된 신호는 JSON으로 직렬화된 다음, 전송 전에 암호화 및 압축됩니다:

1. JSON 직렬화: 모든 신호 값은 신호를 키로 하는 JSON 객체에 담기며, 여기에 메타데이터 필드(API 키를 위한 c, 태그를 위한 t, 연결 ID를 위한 lid)가 추가됩니다.

2. 압축: 페이로드가 1024바이트를 초과하면 CompressionStream("deflate-raw")을 사용하여 압축됩니다.

3. XOR 암호화: 페이로드는 암호화 봉투로 감싸집니다:

   • 임의의 XOR 키 바이트
   • 헤더 바이트(검증 마커)
   • 임의의 패딩(0~3바이트)
   • 9바이트 XOR 마스크
   • 반복되는 마스크로 XOR 연산된 페이로드

4. Base64 인코딩: 암호화된 페이로드는 Base64url로 인코딩되어 POST 본문으로 전송됩니다.

요청은 클라이언트 버전과 API 키에 대한 쿼리 파라미터와 함께 ingress 엔드포인트로 전송됩니다. 퍼스트파티 쿠키를 보내기 위해 CORS 자격 증명이 포함됩니다.

3단계: 서버 측 처리

서버는 암호화된 페이로드를 수신하여 여러 하위 시스템을 통해 처리합니다:

신호 추출

서버는 XOR 봉투를 디코딩하고, 필요 시 압축을 해제한 다음, JSON 신호 데이터를 파싱합니다. 각 신호의 상태 코드와 값이 추출되어 검증됩니다.

방문자 ID 계산

방문자 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

각 계층은 지정된 신호를 추출하고, 정규 문자열을 구성한 후, MurmurHash3-x64-128로 해싱합니다. 세 개의 계층 해시는 연결된 후 base62로 인코딩되어 최종 방문자 ID를 생성합니다.

신뢰도 점수 산정

신뢰도 점수(0.0~1.0)는 이 방문자가 올바르게 식별되었다고 시스템이 얼마나 확신하는지를 나타냅니다:

• 쿠키 일치(1.0): _vid_t 쿠키가 알려진 방문자와 일치하면 신뢰도는 최대가 됩니다.
• 첫 방문(0.90): 이전 기록이 없는 신규 방문자는 0.90에서 시작합니다.
• 재방문자: 신뢰도는 신호 빈도 가중치(IDF 기반)와 비트 수준 해밍 거리(Hamming distance)를 사용한 저장된 지문과의 퍼지 매칭으로 계산됩니다.

봇 탐지

봇 탐지 엔진은 여러 탐지기를 실행하고 그 가중된 출력값을 결합해 봇 점수를 산출합니다. hard-fail 신호는 그 자체만으로 봇 판정을 확정합니다. 공개되는 bot.score는 0..100 척도이며, 판정은 bot.result로 전달됩니다. 정확한 임계값은 공개하지 않습니다. 읽을 수 있는 임계값은 곧 거기에 맞춰 조정할 수 있는 임계값이기 때문입니다. 기여하는 탐지기는 다음과 같습니다:

1. Webdriver 플래그 검사(최우선순위)
2. 복합 자동화 신호 분석
3. 정상 봇 UA 매칭 + IP 검증(역방향 DNS)
4. 헤드리스 브라우저 탐지(11개 마커, 임계값 2 이상)
5. eval 길이 이상 탐지
6. 악성 봇 UA 패턴 매칭
7. 자동화 프레임워크 분류(Puppeteer, Playwright, Cypress, Selenium)
8. 에뮬레이터 탐지(모바일 에뮬레이터 점수 산정)
9. DevTools 탐지
10. 프라이버시 브라우저 분류(Tor, Brave, Firefox ETP, Safari ITP)
11. 행동 분석(속도/엔트로피/상호작용)

계측(Frida), 루팅/탈옥, 복제 앱 탐지기는 플랫폼에 존재하지만 그 입력 슬롯은 네이티브 전용입니다. 브라우저 에이전트는 이를 수집하지 않으므로 웹 판정에는 반영되지 않습니다. 웹에서 완전히 동작하는 항목은 봇 탐지를 참고하세요.

스마트 신호 보강

서버 측 보강 신호는 원시 신호 데이터와 IP 인텔리전스로부터 계산됩니다. 여기에는 VPN/프록시/Tor 탐지, IP 지오로케이션, 브라우저 변조 분석, 의심 점수 산정이 포함됩니다.

IP 인텔리전스

IP 인텔리전스 하위 시스템은 다음을 제공합니다:

• VPN / 프록시 / Tor / 데이터센터: 상용 IP 인텔리전스 데이터베이스(IP2Location)를 사용하여 연결 IP로부터 분류
• 지오로케이션: MaxMind GeoIP2를 통한 도시 수준 정확도 및 ASN

4단계: 응답

서버는 다음을 포함하는 JSON 응답을 반환합니다:

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

이것이 브라우저에서 tracio.getResult()가 resolve하는 결과입니다. 정규 bot_result(human / bot / uncertain), 지오로케이션, 스마트 신호를 포함한 전체 보강 이벤트는 webhooks를 통해 서버 측으로 전달되고, Data API로 조회할 수 있으며, 대시보드에 표시됩니다.

클라이언트는 세션 간 지속성을 위해 방문자 토큰을 퍼스트파티 쿠키(365일 만료, SameSite=Lax)와 localStorage 양쪽에 저장합니다.

데이터 흐름 요약

전체 왕복 시간: 밀리초 단위입니다. 대부분은 신호 수집이 차지하며 네트워크 왕복과 서버 측 처리는 그보다 작은 부분입니다. 소요 시간은 방문자의 기기와 연결 상태에 따라 달라집니다. 이 과정은 페이지 렌더링을 막지 않습니다. 에이전트는 비동기로 로드되고, 느려질 수 있는 검사는 저마다 자체 타임아웃으로 제한됩니다.