デジタルフットプリント追跡の裏側の仕組み

インターネットに接続するすべてのデバイスは、技術的な痕跡、すなわちデジタルフットプリントを残します。tracio.aiでは、クッキー、localStorage、あるいはいかなる形の永続的なクライアントサイドストレージにも頼らず、単一のページ読み込み中に収集される130を超えるパッシブシグナルから、このフットプリントを再構築します。この記事では、そのプロセスがどのように機能するのかを正確に説明します。

シグナル収集層

私たちのJavaScriptエージェントが訪問者のブラウザで読み込まれると、複数のカテゴリーにわたるシグナルを同時に収集し始めます。キャンバスのレンダリング、WebGLパラメータのクエリ、AudioContextの処理、フォントの列挙、navigatorプロパティの読み取りが、すべて並列で実行されます。収集プロセス全体は、最新のハードウェアでは50ミリ秒未満で完了します。

重要な洞察は、各シグナルがデバイスのハードウェアとソフトウェアスタックの異なる側面を捉えるということです。キャンバスのレンダリングはGPU、ドライバ、フォントレンダリングエンジンを反映します。WebGLパラメータはグラフィックスカードのモデルと機能を露呈させます。AudioContextは、オーディオDSPが浮動小数点演算をどう処理するかの違いを明らかにします。navigatorプロパティは、CPUコア数、メモリ、プラットフォーム、言語設定を報告します。

私たちのチームは先月、これを20億イベントにわたって計測しました。収集時間の中央値は38msで、99パーセンタイルは52msでした。実は最初に素朴なアプローチ、すなわちシグナルを逐次的に収集する方法を試しました。それは40倍遅かったのです。タイムアウトフェンスを備えた並列収集は、私たちが最初から正しく判断できた設計上の決定の一つでした。

TLSフィンガープリンティング：第一の層

私たちのJavaScriptが実行される前でさえ、ブラウザはすでにTLSハンドシェイクを通じて重要な情報を明らかにしています。Client Helloメッセージには、ブラウザがサポートする暗号スイート、使用するTLS拡張、優先する楕円曲線、受け入れる署名アルゴリズムが含まれています。この情報はブラウザのTLSライブラリによって決まり、ブラウザファミリー、バージョン、オペレーティングシステムによって大きく異なります。

私たちはこのTLSフィンガープリントを、JA4ハッシュを用いて捕捉します。これはJA3に代わる最新の手法で、より優れた粒度とバージョン間の安定性を提供します。JA4ハッシュだけでもChromeとFirefoxとSafariを見分けることができ、しばしば特定のブラウザバージョン範囲まで識別を絞り込みます。私たちのクライアントサイドのシグナルと組み合わせることで、なりすましが極めて困難なクロス検証層を提供します。

キャンバスとGPUのフィンガープリンティング

キャンバスフィンガープリンティングは、異なるGPUが同じ描画命令をピクセルレベルの微妙な違いでレンダリングするという事実を利用します。Canvas APIを使えば、綿密に設計されたシーン、すなわち複数のフォントによる特定の文字列、特定の座標を持つ幾何学的形状、精密なカラーストップを持つグラデーションを描画し、その結果得られるピクセルデータのハッシュを計算できます。

レンダリングの違いは、GPUモデルやドライバのバージョンによって異なる、アンチエイリアシングアルゴリズム、サブピクセルレンダリング、色のブレンディング、フォントヒンティングのばらつきから生じます。同じGPUモデルを搭載した2台のデバイスでも、異なるドライバのバージョンやオペレーティングシステムで動作していれば、異なるキャンバス出力を生成することがあります。これにより、キャンバスハッシュは私たちの最も特徴的なシグナルの一つになっています。

WebGLハードウェアプロファイリング

WebGL API

は、レンダラーやベンダーの文字列をはるかに超える、グラフィックスサブシステムに関する詳細な情報を露呈させます。私たちは最大テクスチャサイズ、シェーダー精度フォーマット、サポートされている拡張、ビューポートの寸法、そしてGPUモデルやドライバ構成によって異なるその他数十のパラメータをクエリします。

これらのパラメータの組み合わせは、詳細なハードウェアプロファイルを作り出します。たとえばNVIDIA RTX 4070を搭載したデバイスは、AMD RX 7800 XTを搭載したデバイスとは異なる最大テクスチャサイズ、異なるシェーダー精度、異なる拡張サポートを報告します。このハードウェアプロファイルは本質的に安定しており、ブラウザの更新では変化せず、ハードウェアやドライバの変更でのみ変化します。

オーディオ処理のフィンガープリンティング

Web Audio APIは、もう一つのハードウェア依存のシグナル源を提供します。私たちはオシレーターノードを作成し、それをダイナミクスコンプレッサーに接続し、出力バッファを計測します。オーディオハードウェアとオペレーティングシステムをまたぐ、浮動小数点精度、DSP実装、リサンプリングアルゴリズムの違いが、出力に計測可能なばらつきを生み出します。

オーディオフィンガープリントは中程度の一意性を持ちますが、卓越した安定性を備えています。オーディオ処理パイプラインは、ユーザーがオーディオハードウェアを交換するかオペレーティングシステムを再インストールしない限り、めったに変化しません。これにより、オーディオシグナルは私たちの多層識別システムにおける貴重なアンカーになっています。

シグナルの統合とアイデンティティ解決

生のシグナルは暗号化されて私たちのサーバーに送信され、そこでデバイス識別エンジンが3層のハッシュシステムを通じてそれらを処理します。ハードウェアレベルのシグナル（キャンバス、WebGL、オーディオ）がTier 1、すなわち安定した中核のアイデンティティを形成します。ブラウザレベルのシグナル（機能検出、CSSプロパティ、メディア機能）はTier 2を形成し、ブラウザの更新による予測されるドリフトに対処するためにセッション間のマッチングを通じて処理されます。揮発性のシグナル（ユーザーエージェント、タイムゾーン、言語）はTier 3を形成し、アイデンティティの判断を左右することなく信頼度スコアリングに寄与します。

統合アルゴリズムは、各シグナルをその一意性と安定性で重み付けします。まれなキャンバスハッシュでのマッチは、ありふれた画面解像度でのマッチよりはるかに大きな重みを持ちます。この重み付けアプローチにより、シグナルの一部が変化しても識別は正確なままに保たれます。

ストレージなし、クッキーなし

私たちのシステムの重要な設計原則は、識別がいかなる形のクライアントサイドストレージにも依存しないということです。私たちはトラッキングの目的でクッキーを設定したり、localStorageに書き込んだり、IndexedDBを使ったりしません。訪問者IDは完全にデバイス固有の特性、すなわちハードウェア、ソフトウェアスタック、ネットワーク構成から導き出されます。これは、識別がクッキーの削除、シークレットモード、さらにはブラウザの再インストールを乗り越えて維持されることを意味します。

アーキテクチャによるプライバシー

私たちは技術的なブラウザ属性のみを収集し、閲覧履歴、フォームデータ、個人的なコンテンツは収集しないため、プライバシーへの影響は最小限です。W3Cフィンガープリンティングガイダンスは、ブラウザシグナルの責任ある利用のためのベストプラクティスを示しており、私たちのアーキテクチャはこれらの原則と合致しています。クラウドホスト型のデプロイでは、すべての処理がお客様のインフラ上で行われます。訪問者のデータが私たちのサーバーに届くことは一切ありません。このアーキテクチャにより、GDPR、CCPA、その他のプライバシー規制への準拠が容易になります。