仕組み

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() が呼び出されると、クライアントは階層に整理された300+個の異なるブラウザシグナルを収集します。収集は、パフォーマンスのためにWeb Workerと共有iframeを用いる多段階パイプラインを使用します。

シグナルのカテゴリ

エージェントは15カテゴリにわたる303個のシグナルを搭載しています:

Canvasは2Dレンダリングと同様にWebGLとWebGPUもカバーします。Tamperが2番目に大きなカテゴリなのは、改変された環境を見分けるには、手を加えられていない環境を読み取るよりも多くのプローブが必要だからです。

収集パイプライン

収集パイプラインは、メインスレッドのブロッキングを最小化するために4つのステージで実行されます:

1. ステージ1（即時）: 収集が速い高優先度シグナル（navigatorプロパティ、スクリーン、タイムゾーン）。TURNプローブも、並行して動作するためここで開始します。

2. ステージ2（アイドルコールバック）: アイドル期間が有益な同期シグナル（CSSメディアクエリ、ストレージプローブ、cookieテスト）。

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、tag用の t、linked ID用の lid）が追加されます。

2. 圧縮: ペイロードが1024バイトを超える場合、CompressionStream("deflate-raw") を用いて圧縮されます。

3. XOR暗号化: ペイロードは暗号化エンベロープにラップされます:

   • ランダムなXORキーバイト
   • ヘッダーバイト（検証マーカー）
   • ランダムなパディング（0-3バイト）
   • 9バイトのXORマスク
   • 繰り返しマスクでXORされたペイロード

4. Base64エンコード: 暗号化されたペイロードはBase64urlエンコードされ、POSTボディとして送信されます。

リクエストは、クライアントバージョンとAPIキーのクエリパラメータとともにイングレスエンドポイントに送信されます。ファーストパーティCookieを送信するためにCORS credentialsが含まれます。

ステージ3: サーバーサイド処理

サーバーは暗号化されたペイロードを受信し、複数のサブシステムを通じて処理します:

シグナル抽出

サーバーは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 でハッシュ化します。3つの層のハッシュは連結され、base62でエンコードされて最終的な訪問者IDが生成されます。

信頼度スコアリング

信頼度スコア（0.0〜1.0）は、この訪問者が正しく識別されたことをシステムがどれだけ確信しているかを示します:

• Cookie一致（1.0）: _vid_t cookieが既知の訪問者と一致する場合、信頼度は最大になります。
• 初回訪問（0.90）: 事前の記録がない新規訪問者は0.90から始まります。
• 再訪問者: 信頼度は、シグナル頻度の重み付け（IDFベース）と、ビットレベルのハミング距離を用いた保存済みフィンガープリントとのファジーマッチングから計算されます。

ボット検知

ボット検知エンジンは複数の検知器を実行し、その重み付けされた出力を組み合わせてボットスコアを算出します。ハードフェイル（hard-fail）シグナルは、それ単独でボット判定を確定させます。公開される bot.score は 0..100 のスケールで、判定は bot.result として返されます。正確なしきい値は公開していません。読み取れるしきい値は、それに合わせて調整できるしきい値だからです。寄与する検知器には以下が含まれます:

1. Webdriverフラグチェック（最高優先度）
2. 複合的な自動化シグナル分析
3. 良性ボットのUAマッチング + IP検証（逆引きDNS）
4. ヘッドレスブラウザ検知（11個のマーカー、しきい値2+）
5. eval lengthの異常検知
6. 悪質ボットのUAパターンマッチング
7. 自動化フレームワークの分類（Puppeteer、Playwright、Cypress、Selenium）
8. エミュレータ検知（モバイルエミュレータのスコアリング）
9. DevTools検知
10. プライバシーブラウザの分類（Tor、Brave、Firefox ETP、Safari ITP）
11. 挙動分析（レート/エントロピー/インタラクション）

インストルメンテーション（Frida）、root/jailbreak、クローンアプリの検知器はプラットフォームに存在しますが、その入力スロットはネイティブ専用です。ブラウザエージェントはこれらを収集しないため、ウェブでの判定には寄与しません。ウェブで完全に動作するものについてはボット検知を参照してください。

Smart Signalのエンリッチメント

サーバーサイドのエンリッチメントシグナルは、生のシグナルデータとIP intelligenceから計算されます。これらには、VPN/プロキシ/Tor検知、IP位置情報、ブラウザ改ざん分析、疑わしさスコアリングが含まれます。

IP Intelligence

IP intelligenceサブシステムは以下を提供します:

• VPN / プロキシ / Tor / データセンター: 接続元IPから、商用のIP intelligenceデータベース（IP2Location）を用いて分類
• 位置情報: MaxMind GeoIP2による市区町村レベルの精度とASN

ステージ4: レスポンス

サーバーは以下を含むJSONレスポンスを返します:

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

これは、ブラウザ内で tracio.getResult() が解決する結果です。正規の bot_result（human / bot / uncertain）、位置情報、smart signalsを含む、完全にエンリッチされたイベントは、webhooksを通じてサーバーサイドに配信され、Server APIから読み取ることができ、ダッシュボードに表示されます。

クライアントは、セッションをまたいだ永続化のために、ファーストパーティCookie（365日で失効、SameSite=Lax）とlocalStorageの両方に訪問者トークンを保存します。

データフローの概要

合計ラウンドトリップ: ミリ秒単位です。その大半を占めるのはシグナル収集で、ネットワークの往復とサーバー側の処理はより小さな部分です。所要時間は訪問者の端末と回線に左右されます。ここでページのレンダリングがブロックされることはありません。エージェントは非同期に読み込まれ、時間がかかりうる検査はそれぞれ独自のタイムアウトで制限されています。