Canvas、WebGL、Audio: ブラウザを再起動しても消えない三つのフィンガープリント

なぜ無数のうちこの三つなのか

現代の fingerprinting スクリプトは、典型的なページで約 40 のベクターを覗き込みます。User-Agent、画面サイズ、言語ヘッダ、フォントリスト、インストール済みプラグイン、タイムゾーンのオフセット、ポインタ精度、hardware concurrency。これらはほとんどが短い整数や短い文字列で、実際にはそれぞれ 1 ビットから 5 ビット程度のエントロピーしか持ちません。接着剤としては役立ちますが、識別子としては心もとない、という位置づけです。

Canvas、WebGL、AudioContext は事情が違います。どれも決まった処理をデバイスに通し、その出力をハッシュ化する仕組みです。ハッシュは GPU シリコン、ドライババージョン、OS のフォントラスタライザ、アンチエイリアス戦略、そしてオーディオサブシステムの浮動小数点実装に左右されます。だからこそ、同じマシン上で新規インストールした Chrome は翌日もほぼ同じ三つのハッシュを返し、同じマシンでも GPU ドライバが変われば明らかに別のハッシュが出てくるわけです。

EFF の Cover Your Tracks データセットや Inria の AmIUnique コーパスの数字によれば、canvas ハッシュはおよそ 10 ビット、WebGL の renderer 情報は 6〜8 ビット、AudioContext は 4〜5 ビット程度のエントロピーを持ちます。三つすべてを露出するセッションは 18 ビットを軽く超え、25 万人の中から一人を絞り込むには十分です。広告ターゲティング、不正スコアリング、たいていの解析パイプラインにとっては十分すぎる情報量と言えます。

Canvas fingerprinting を詳しく

Canvas fingerprint は、ブラウザが描画したにもかかわらず、あなたには見せなかった画像のハッシュです。スクリプトは画面外に <canvas> を作り、いくつかの図形と 2〜3 種類のフォントを使った文字列を流し込んでから toDataURL() を呼び、得られた PNG のバイト列をハッシュ化します。ユーザーには何も表示されず、処理全体は数ミリ秒で完了します。

ある特定のマシン上でこのハッシュが安定するのは、レンダリング経路が決定的だからです。同じ GPU、同じドライバ、同じ OS のフォントラスタライザ、同じアンチエイリアス設定なら、PNG はバイト単位で一致します。そのうち一つでも変われば、ハッシュは飛びます。Windows の機能更新によって、それまで安定していたユーザーがトラッカーから見て突然「新規」になる理由も、ドライバを固定した法人マシンが互いによく似て見える理由も、ここにあります。

攻撃の骨格はおおむね次のような形です。

const c = document.createElement("canvas");
const ctx = c.getContext("2d");
ctx.textBaseline = "alphabetic";
ctx.font = "14px 'Arial'";
ctx.fillStyle = "#069";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 2, 15);
ctx.fillStyle = "rgba(102,204,0,0.7)";
ctx.fillText("Cwm fjordbank glyphs vext quiz, ", 4, 17);
const png = c.toDataURL();
// hash(png) があなたの canvas fingerprint になる

このスニペットは特別な代物ではありません。FingerprintJS、ThreatMetrix、Cloudflare Bot Management が初回アクセス時に走らせているルーチンと、本質的には同じものです。Brave や uBlock Origin は、読み出しの前にセッションごとの小さなノイズを差し込むことで、毎回ハッシュを変えます。素朴な集計に対しては有効ですが、その防御自体が検出可能です。決して繰り返さないハッシュは、それ自体がシグナルとなり、トラッカーはあなたを「canvas ランダム化を入れているユーザー」のカテゴリに振り分けてきます。

WebGL fingerprinting を詳しく

WebGL は、OpenGL ES API の JavaScript ラッパーを介して、ページに GPU への直接アクセスを許可します。すぐに気になる点が二つあります。第一に、 WEBGL_debug_renderer_info という小さな拡張機能が、GPU ベンダーと renderer 文字列を文字どおりそのまま晒してしまいます。多くのデスクトップでは ANGLE (NVIDIA, GeForce RTX 4070, OpenGL 4.5.0) のような、かなり具体的な値になります。この一つの文字列だけで 10 ビット超のエントロピーを持ちうるのは、ドライバのブランチや、ときにはビルドハッシュまで含むからです。

第二に、その拡張機能が隠されたり無効化されていても、テクスチャ付きのトーラス、グラデーションスフィア、いくつかの回転した三角形といった中程度に複雑な 3D シーンのレンダリング結果は依然としてハッシュ化できます。シェーダコンパイラ、精度設定、ブレンディング実装の違いが、ピクセルをわずかに、しかし一定のパターンで動かすからです。スクリプトは readPixels() でフレームバッファを読み戻し、ハッシュ化して結果を保存します。

WebGL を完全に無効化するのが最もきれいで、最も代償の大きい防御です。Google Maps、ほとんどのブラウザゲーム、GPU 上でチャートを描画する現代の SaaS ツールの半数、そして驚くほど多くの EC サイトの 3D ビューワが動かなくなります。Firefox はそれを受け入れるユーザー向けに webgl.disabled 設定を用意しています。Tor Browser は WebGL を有効にしたまま、同じプラットフォーム上のすべての Tor インストールで renderer 文字列を単一の値に正規化します。だからこそ、まったく異なるハードウェアの Tor ユーザー二人が、ページに対して同じ WebGL 署名を返すことになります。

AudioContext fingerprinting を詳しく

AudioContext fingerprinting は、あらゆる意味で三つの中で最も静かなベクターです。スクリプトは OfflineAudioContext をインスタンス化し、固定周波数の三角波またはサイン波を生成し、パラメータを固定したダイナミクスコンプレッサに通したうえで、サンプルを Float32Array として読み戻します。実際の音がスピーカから出ることはありません。ミュートが解除されている必要もありませんし、ヘッドフォンがあるかどうかも関係ありません。重要なのは、それらのサンプルを生成するためにオーディオスタックが使った浮動小数点演算です。

人間の耳にとって、出力されるオーディオは同じに聞こえます (可聴域の内容しか見ないスペクトルアナライザから見ても同じです) が、その裏側にある float32 の値はコンプレッサアルゴリズムの実装ごとに差が出ます。ブラウザのビルド、OS のオーディオエンジン、さらには一部の CPU マイクロコードリビジョンが、最下位ビットを一定のパターンで動かすのです。バッファをハッシュ化するか合計をとれば、再起動、プロファイルリセット、ほとんどの拡張機能をくぐり抜ける数字が得られます。

AudioContext は canvas よりエントロピーが小さく (おおむね 4〜5 ビット) 、単独では誰かを特定するほどではありません。トラッカーにとっての本当の価値は、ほぼ誰も対策を取っていない点にあります。Canvas と WebGL はプライバシーツールから派手な注目を浴びますが、オーディオはその陰に隠れています。二つのセッションをまたいで一致する canvas ハッシュとオーディオハッシュが見つかれば、その一致に対する確信は、canvas 単独で持てるものよりはるかに高くなります。オーディオの数字が偶然一致することはまずないからです。

三つの比較

並べて見ると、三つのベクターはそれぞれ違う強みを持ちます。下の表は、各ベクターがトラッカーに何を与え、防御にいくらかかり、その防御自体がどれほど目立つかをまとめたものです。

構図は一貫しています。各ベクター単独で突破するのは難しく、効果のある防御はそれ自体が目立ちます。canvas は普通、WebGL が普通なのに AudioContext のフラグだけが欠けているユーザーは、母集団のごく一部に過ぎず、そのこと自体が識別の手がかりになってしまいます。

Tor が一つを漏らしてしまう理由

Tor Browser は、静的 fingerprinting に対する消費者向け防御として最も強硬です。既定では canvas の読み出しは一様な白画像を返します (実データを渡す前にユーザーへ確認が入ります)。WebGL は有効ですが、renderer 文字列は同じプラットフォーム上のすべての Tor インストールで単一の値に正規化され、レンダリング出力もドライバ差を消すために丸められます。Tor 内では、三つのうち二つは事実上死んでいると言ってよい状態です。

残るほころびが AudioContext です。Tor Project の脅威モデルにはきちんと含まれており ( tor-browser#13017 のチケットや関連する Mozilla のバグレポートは何年も前から続いています) 、それでも OfflineAudioContext の浮動小数点出力はビルドチェーンに依存し続けています。Linux x86_64 上の Tor Browser と macOS arm64 上の Tor Browser は、同じプラットフォーム文字列を報告していても、測定可能なほど異なるオーディオハッシュを出します。Tor に対して機能する AudioContext distinguisher は、最初の AmIUnique 論文をはじめ、新しい学術論文でも繰り返し発表されています。

この問題を直すのが難しいのは、対策の選択肢が OfflineAudioContext を全面的に無効化することになるからです。そうすれば、裏でオーディオをデコードしているあらゆる Web アプリ (podcast プレーヤ、ビデオ会議、ブラウザゲーム、アクセシビリティツール) が壊れます。Tor Project はこの変更について慎重な姿勢を崩しておらず、結果として、最も入念に堅牢化された消費者向けブラウザでさえ、三つのうち一つを露出し続けています。

本当に効く対策

三つのベクターには共通点があります。どれも物理ハードウェアの挙動から導かれます。ソフトウェアだけの防御も助けにはなりますが、完全な答えはどれも、マシンが本当に何であるかではなく、ページがマシンから何を見るかを変えるものです。

FAQ

ここから何ができるか

Canvas、WebGL、AudioContext を合わせると、典型的なセッションで 18 ビットのエントロピーを超えます。25 万人の中から一人を絞り込むには十分な量で、cookie 時代向けのあらゆるツール (シークレット、VPN、ほとんどのプライバシー拡張機能) はこの三つに手を触れないままです。ハッシュは GPU、ドライバ、フォント、オーディオスタックから生まれ、それらのツールが決して届かない層こそが、まさにこの層です。

一つずつ防いでも、その動き自体が目立ちます。canvas ランダム化、WebGL マスク、オーディオノイズはいずれも検出可能な異常として現れ、トラッカーは「防御済み」ユーザーをより小さく、ある意味でより興味深いカテゴリに振り分けます。Tor は三つのうち二つを納得のいく形で塞ぎますが、オーディオ署名はそのまま漏らし続けます。三つすべてを塞ぐ唯一の解は、ページが目にできるハードウェアとソフトウェアスタックそのものを変えることです。実務的には、別の物理マシン、別の OS インストール、あるいは Browser.lol のようなコンテナ化されたリモートブラウザを使う、ということになります。