ブラウザ指紋テスト:Canvas・WebGL・AudioContext・端末一意性診断

詳細フィンガープリントと環境評価

ブラウザ指紋テスト

ブラウザフィンガープリントは、ハードウェア、フォント、描画特徴を収集して生成される一意の識別 ID です。

SHA-256 Hash 確認中...
改ざん検出
確認中...
Bot 判定
確認中...
WebRTC 漏洩
確認中...
一意性スコア
確認中...

ハードウェアと基本環境

確認中...

                            

グラフィックスとレンダリング

確認中...

                            

ブラウザとセキュリティ

確認中...

                            

高度なフィンガープリント

確認中...

                            

ネットワークと WebRTC

確認中...

                            

機能プローブと環境

確認中...

                            

ブラウザ指紋の総合診断と露出概要

確認中...
確認中...
クロスレイヤー・ネットワークスタック分析

ブラウザ側の Canvas/WebGL 一意性とサーバー側の TCP/TLS/QUIC パケット指紋を組み合わせ、総合的な追跡リスクを評価します。

ネットワーク指紋を診断 →

ブラウザフィンガープリントに関するよくある質問

ブラウザ指紋の仕組み、クロスレイヤー矛盾検知、アンチディテクトブラウザの限界、シークレットモードの実態を解説します。

User-Agent文字列だけを変更してもブラウザを隠すことはできず、かえって目立つ「クロスレイヤー矛盾」を引き起こして高度な不正検知に捕捉されます:第一にアプリケーション層とトランスポート層の不一致:Windows上でUAをiPhone Safariに変更した場合、HTTPヘッダーはApple端末と主張しますが、TCP SYNパケットはWindowsカーネルの署名(TSオプションなし、オプション順序MSS, NOP, WS, NOP, NOP, SACK_PERM)を示し、Apple特有の8項目オプション順序と真っ向から矛盾します。第二にHTTP/3およびHTTP/2のプロトコル不変特性:Chromium、WebKit、Geckoエンジンは偽装困難な固有動作を持ち、HTTP/3の一方向ストリーム型マッピング(Chromium: 2:control,10:encoder vs WebKit: 2:control,6:encoder)やHTTP/2の疑似ヘッダー順序(Chromium: m,a,s,p vs 非Chromium: m,s,a,p)に明らかな差があります。表層ヘッダーの変更だけでは下位ネットワーク層との矛盾を隠せません。

💡 トランスポート層の署名詳細については、プロキシ匿名性分析をご確認ください。

アンチディテクトブラウザは通常、Chromiumの改造やJavaScriptフックの注入によってnavigatorプロパティを上書きし、Canvas/WebGLの出力にノイズを加え、画面解像度やオーディオコンテキストを偽装します。しかし、高度な検知システムは特有の痕跡を容易に見破ります:第一にプロトタイプとネイティブ関数の改ざん痕跡:JSフックはFunction.prototype.toString、プロパティ記述子、プロトタイプ継承チェーンに不自然な変更を残します。第二にGPUおよびシェーダーの不変特性:ノイズ注入で画像ハッシュ値が変わっても、物理GPUの浮動小数点演算精度やラスタライズ挙動自体は不変であり、注入されたノイズ自体が識別可能なパターンを形成します。第三に未修正のOSネットワークスタック:大半の偽装ブラウザはJS層でのみ動作し、ホストOSのTCP/TLSハンドシェイク特性までは偽装できません。

いいえ、防止できません。シークレットモードは「お使いの端末内に閲覧履歴を残さない」ことのみを目的として設計されており、「Webサイトによるリモート識別」を防ぐ機能はありません。ウィンドウを閉じるとクッキー、LocalStorage、履歴は破棄されますが、ブラウザ指紋はJavaScriptを通じて物理ハードウェアとレンダリング特性(GPUグラフィックス描画、WebGLシェーダー精度、インストールフォント、オーディオ発振器の応答、CPUコア数、色深度など)を計測します。物理ハードウェア、ドライバ、ブラウザエンジンはシークレットモードでも同一であるため、リモートサーバーが算出する指紋ハッシュは通常モードと完全に一致します。

これは誤検知ではなく、iOSプラットフォームの基本仕様に基づく正確な判定です:第一にApple App Storeのガイドライン:AppleはiOS/iPadOS上のすべてのWebブラウザ(Chrome、Edge、Firefox、Operaを含む)に対して、自社製WebKit / WKWebViewレンダリングエンジンの使用を義務付けており、Chromium BlinkやGeckoエンジンの搭載を認めていません。第二にプロトコルレベルの検証:iOS版Chrome(CriOS)はHTTP/3接続時にWebKit専用の一方向ストリームマッピング(2:control,6:encoder)を送信し、PCやAndroid上のChromium(2:control,10:encoder)とは根本的に異なります。iOS上のChromeは「Google製UIを被せたWebKitブラウザ」であるため、WebKitと判定するのが技術的に正当です。

はい、ただし明確な条件と上限があり、これは「本人認証」とは全く異なる仕組みです。当サイトの身元復元は 4 層の重み付けモデルを採用しています:第一にハードウェアアンカー層(GPU 型番、サウンドカードの基準レイテンシ、メディアデバイス数);第二にシステム高エントロピー層(インストール済みフォント一覧、音声合成ボイス一覧);第三にブラウザ可変層(Canvas 描画ハッシュ、AudioContext 演算ハッシュ);第四に表示環境層(画面解像度、タイムゾーン)。4 層を合算後、既存の識別情報として照合するには以下の 2 つの条件を同時に満たす必要があります:総合スコアが基準値を超えていること、かつ高エントロピー中核特徴の少なくとも 1 つに一致していること(フォント一覧、音声合成、Canvas、Audio のいずれか)。この 2 つ目の条件は意図的に設けられたものです。GPU 型番、タイムゾーン、解像度といった公開された低エントロピー属性は同型機器間で大量に重複するため、どのような組み合わせであっても単独で身元を特定することは許可されません。この条件がなかった初期バージョンでは、これら 3 項目だけで初見の別端末を誤認識するリスクがありました。さらに、ハードウェアアンカー層は一票拒否権を持ちます:CPU 論理コア数の相違、4GB を超えるメモリ容量差、0.005 秒を超える音声基準レイテンシ差、最大タッチ点数の相違のいずれかに該当する場合、スコア集計に進むことなく即座に別端末と判定されます。

⚠ この仕組みの目的は同一端末の反復観測データを安定して紐付けることであり、利用者個人の特定を証明するものではありません。身元認証を構成するものではなく、認証目的で使用すべきではありません。

いずれも「システム高エントロピー特徴」に分類され、権限要求が不要で画面上にも一切変化が見えない点が共通しています。AudioContext 指紋:OfflineAudioContext 内で発振器(Oscillator)をダイナミクスコンプレッサー(DynamicsCompressor)に接続して波形をオフラインレンダリングし、取得した浮動小数点サンプル値からハッシュを算出します。同一のオーディオグラフでも、ブラウザの実装、数学ライブラリ、浮動小数点バックエンドの違いによって最下位ビットに微細な差異が生じます。全行程が無音であり音は鳴りません。これと並行しつつも完全に独立しているのが AudioContext.baseLatency です:この値はサウンドカードの出力バッファサイズを示し、オーディオドライバとハードウェアに依存します。当サイトではこれを識別ハッシュではなくハードウェアアンカーとして利用しており(0.005 秒を超える差異は別端末と判定)、両者は出所が異なるため混同してはなりません。フォント列挙指紋:候補フォント一覧の各フォントで同一文字列を描画した際の幅と高さを測定し、フォールバックフォントとの差異から導入済みフォントを判定します。導入済みフォントは過去に導入したソフトウェア(Office、Adobe 製品、開発ツール、IME 等)に強く依存するため、フォント一覧は通常、全特徴の中で最も識別能力が高い単一指標となります。

💡 安定性の差は変化の契機にあります:Canvas と Audio のハッシュはブラウザのバージョン更新に伴い変動しますが(描画スタックと演算ライブラリが常に更新されるため)、フォント一覧はソフトウェアの追加・削除を行わない限り変動しません。これがフォントに最も高い配点が与えられている理由です。

MSS(Maximum Segment Size)は TCP ハンドシェイク時に通知される 1 パケットあたりの最大ペイロードであり、当サイトは追加のソフトウェアや設定を要求することなく、受信した SYN パケットから直接読み取ります。これに IP および TCP ヘッダーのオーバーヘッドを加算することで通信経路の MTU が復元されます:IPv4 は 40 バイト加算、IPv6 は 60 バイト加算。代表的な値には明確な技術的意味があります:1500 は標準イーサネットまたはクラウド基盤の生リンク;1492 は PPPoE 接続(光回線や DSL などの家庭用ブロードバンド)で、8 バイトの PPPoE ヘッダー分減少します;1420 以下は WireGuard / Tailscale などの VPN トンネルや CDN オリジン転送によりパケットが再カプセル化されていることを示します。

⚠ 重要なのは、MSS は端末ではなく通信経路の特性を示す指標であるという点です。これは経路上にカプセル化が存在することを示すのみで、単体ではプロキシ使用の証明にはなりません(家庭用回線の PPPoE も 1500 ではありません)。真の診断価値は矛盾の検出にあります:アプリケーション層が主張するロケーションと経路特性が恒常的に乖離している場合(直接接続を主張しながら MSS がトンネル帯に固定されている等)、初めて有意義な判定シグナルとなります。詳細は プロキシ匿名性分析 をご覧ください。

これは当サイトが最も警戒している誤判定(誤統合)であり、3 重の防御策を講じています。いずれか 1 つでも阻止されれば統合は行われません。第一にバケット完全隔離:候補はまず OS プラットフォームとブラウザ内核ごとに厳格に分類され、バケットを跨いだ比較は一切行われません。そのため、同一物理端末上の異なる内核ブラウザ同士であっても、ハードウェア構成が完全に同一であっても統合されることは決してありません。第二にハードウェアアンカーの一票拒否権:CPU 論理コア数、メモリ容量(許容誤差 4GB)、オーディオ基準レイテンシ(许容誤差 0.005 秒)、最大タッチ点数のいずれかが両者で測定され許容範囲を超えて衝突した場合、スコア判定に進むことなく除外されます。第三に中核特徴の入場ゲート:総合スコアがどれほど高くとも、高エントロピー中核特徴(フォント、音声合成、Canvas、Audio)のいずれにも合致しない場合は照合を許可しません。これは公開された低エントロピー属性の集積による不当な高スコアを防ぐための防壁です。

⚠ 正直な説明:現時点において、自然トラフィックに基づく誤統合率の公表可能な実測値は存在しません。この指標は長期的な実アクセスデータの蓄積により初めて正確に算出できるものであり、十分な標本数が揃う前に推計値を公表することは誠実な技術姿勢ではないと考えています。