アンチディテクトブラウザの信頼性検証方法：チェックリストと採点表

フィンガープリント検出サイトが「合格」を示しても、ブラウザが信頼できるとは限りません。本記事では、フィンガープリントの一貫性、環境の分離、WebRTC/DNS/IPv6リーク、プロキシ切断、カーネル更新、権限、復旧、データ管理を網羅する再現可能なテスト方法を提供します。

アンチディテクトブラウザの検証は、検出サイトを1つ開いて緑色の表示を見て終わり、というわけにはいきません。検出ページは、それが実装している項目しか観察できません。環境が長期的に安定していること、異なる環境がデータを混在させないこと、プロキシ切断時にローカルネットワークを露出しないこと、チームの権限・誤削除からの復旧・アップグレード互換性が健全であることを証明することはできません。

製品が信頼できるかどうかは、5つの問いに分解すべきです。同じ環境を複数回起動しても一貫しているか。異なる環境は設計どおり分離されているか。ネットワーク出口とWebRTC・DNS・IPv6はプロキシポリシーに合致しているか。実際の業務サイトと互換性があるか。チームのデータ・権限・復旧は制御可能か。これら5つのカテゴリーのテストを繰り返し、結果を保存して初めて、比較可能な結論が得られます。

「ワンステップの検証」ではなぜ不十分か？

フィンガープリント検出のサードパーティサイトだけに頼って判断すると、「オールグリーン」の画面に説得されやすくなります。問題は次のとおりです。

検出サイトごとに収集する項目が異なるため、カバー範囲が一致しません。
「リークなし」と表示されても、プロキシ切断時の安全性は保証されません。
1回の結果では、再起動やアップグレードをまたいだ安定性はわかりません。
ランダム生成された項目は、一時的には妥当に見えても、長期的には頻繁に変わり得ます。
検出ページは、対象プラットフォームのリスク管理モデルを知りません。
メンバーの権限、クラウドデータ、バックアップ、監査ログは確認できません。
技術的に正常な環境でも、虚偽のプロフィール、スパムコンテンツ、異常な操作を補うことはできません。

つまり、サードパーティの検出ページは測定ツールであり、セキュリティ証明書ではありません。最終的な答えではなく、観察可能なシグナルの源泉として使いましょう。

まず「信頼できる」の受入基準を定義する

テスト前に、要件を観察可能な結果として書き出します。

次元	合格基準の例	失敗症状
フィンガープリントの一貫性	同じ環境を再起動しても安定項目が同じ	Canvas、GPU、言語が理由なく変わる
パラメータの整合性	UA、カーネル、OS、フォントが互いに妥当	macOSを名乗りながら明らかにWindowsの組み合わせ
環境の分離	Cookie、ローカルストレージ、拡張機能が環境をまたがない	Aのログイン状態がBに現れる
ネットワーク出口	IP、WebRTC、DNS、IPv6がポリシーに一致	プロキシIPとローカル出口が同時に現れる
障害処理	プロキシ失敗時に明確な遮断または警告	静かにローカルネットワークへフォールバック
互換性	主要サイト、アップロード、決済、動画が動作	ページクラッシュ、認証ループ、拡張機能の破損
復旧可能性	削除・端末変更・アップグレードを定められた手順で復旧	設定やセッションが永久に失われる
チームガバナンス	最小権限、ログ、退職時の剥奪が実行可能	全員が管理者アカウントを使う

「すべての項目が異なる」ことは合格基準ではありません。フィンガープリントは事前設定の環境と整合し、同じ環境が変化を求めるがために毎回ランダムに再構成されるべきではありません。

再現可能なテスト環境を準備する

テスト対象

最低限、以下を準備します。

ネイティブブラウザのベースライン環境 1つ。
アンチディテクトブラウザの環境AとB。
異なる地域またはプロトコルのテスト用プロキシ2つ。
端末切り替えテスト用のメイン端末1台と予備端末1台。
自社サイト専用のテスト用アカウント。顧客の本番アカウントは使いません。

ここでの要点は、「テスト対象の環境」が、いつでも再構築でき、明確に名前を付けられるテスト用ワークスペースでなければならないことです。PurpleMarkのWebアプリでワークスペースを作成する際、プラットフォームやアカウントごとに環境グループを構成し、テスト用の環境A・B、テスト用プロキシ、専用テストアカウントを1つのグループにまとめ、各環境に明示的なOS、言語、タイムゾーンを割り当てると、後でどの設定が違いを生んだのか特定しやすくなります。

記録シート

各テストで、日付、製品バージョン、ブラウザカーネル、OS、環境ID、プロキシ、検出サイト、結果スクリーンショット、異常を記録します。スクリーンショットは必要な項目だけを残し、IP・アカウント・キー・端末識別子をマスクします。

4つの時点で繰り返します。最初の作成直後、閉じて再度開いた後、PCの再起動後、製品またはカーネルのアップグレード後。1回だけのテストでは、時間経過に伴う安定性の問題は見つけられません。

ステップ1：ネイティブブラウザのベースラインを確立する

まず通常のChrome、Firefox、Edgeで検出を実行し、この端末が通常どんな項目を露出するのか理解します。ベースラインは「正解」ではなく、アンチディテクトブラウザが事前設定の項目を実際に変更したか、明白なローカル特性を残していないかを識別するのに役立ちます。

EFFのCover Your Tracksは、トラッカーがブラウザをどう見るかを示し、最も識別力の高い特性の概要を提供します。一意性とトラッキング保護の観察に適していますが、結果は訪問者集団、ブラウザバージョン、テスト時期に影響されます。「一意性が低いほど安全」と単純に読まないでください。

次の項目を記録します。

ブラウザとカーネルのバージョン。
OSとアーキテクチャ。
画面サイズ、色深度、ズーム。
タイムゾーン、言語、地域。
フォントとメディアデバイスの露出。
Canvas、WebGL、Audioなどの概要。
Client Hints、タッチポイント、ハードウェア並列度。
リモートIP、IPv6、WebRTC候補アドレス。

ステップ2：同じ環境の時間的一貫性をテストする

環境Aで、順に以下を実行します。

起動して最初の検出を完了します。
環境を閉じ、再起動して検出します。
PCを再起動した後、再び検出します。
環境設定を変えずにネットワークを切り替え、検出します。
製品またはカーネルをアップグレードした後、再び検出します。

結果をカテゴリー別に比較します。

安定すべき項目：環境名、事前設定OS、言語、フォント戦略、画面、Canvas/WebGL戦略。
ネットワークとともに変わり得る項目：公衆IP、ネットワークの場所、遅延。
バージョンとともに変わり得る項目：カーネル、UA、Client Hints。ただし変化はアップグレードと整合するべき。
説明が必要な項目：設定変更なしで跳ぶGPU、フォント、デバイス名、タイムゾーン。

信頼できる製品は、変化を「予測可能・説明可能・監査可能」にすべきです。起動ごとにランダムな項目が変わったら、ベンダーに設計意図を確認し、対象業務で再認証が発生しないかテストします。

PurpleMarkでテストする場合、このステップの焦点は、「同じ名前の環境を2回開いても事前設定パラメータが維持されるか」を検証することです。同じ環境を閉じて再度開いたとき、OS、言語、タイムゾーン、WebRTCなどの設定項目が毎回新しいフィンガープリントを生成するのではなく、理想的には同じままであるべきです。説明できない跳びがあれば、検出サイトのせいにするのではなく、その環境のフィンガープリント・端末設定ページを確認します。

ステップ3：異なる環境間の分離と整合性を比較する

環境AとBは、すべての項目が異なる必要はありませんが、共有すべきでないデータを共有すべきではありません。テストします。

Aでテストサイトにログインした後、Bはログアウト状態のままか。
AがCookie、ローカルストレージ、IndexedDBを書き込んだら、Bでは不可視か。
Aが拡張機能をインストールしたりブックマークを追加したら、Bは設定どおり独立を保つか。
Aがプロキシ・言語・タイムゾーンを変更したら、Bは影響を受けないか。
両環境を同時実行したとき、クリップボード、ダウンロードディレクトリ、ファイルアクセス境界は明確か。
チームがAを共有したとき、Bのリソースも誤って共有されないか。

AmIUniqueは、ブラウザフィンガープリントを、ブラウザ・OS・画面・アーキテクチャ・フォント・プラグイン・マイク・カメラなどの情報を体系的に収集し、フィンガープリントの多様性を研究するものと定義しています。このサイトはデータとCookieの扱いを説明しています。テスト前にプライバシー通知を読み、機密の業務データを含む環境でむやみに送信しないでください。

環境間の比較では、ハッシュが異なるかどうかではなく、「組み合わせが妥当か」に注目します。2つのハッシュが異なっても、無関係な1項目の変化を反映しているだけかもしれません。2つのハッシュが同じでも、すべてのセッションデータが共有されているとは限りません。

AとBがPurpleMarkの2つの独立環境の場合、ログイン状態、Cookie、ローカルデータが分離されたままで、一方を開いても他方のセッションが表示されないことも確認できます。これはまさに、環境とデータの分離の受入で問われる点です。

ステップ4：IP、WebRTC、DNS、IPv6を確認する

ネットワークテストでは、少なくとも4つの状況をカバーします。プロキシ正常、プロキシ切断、プロキシ切替、システムネットワークの変更です。

公衆IP

リモートページが見る公衆アドレスは、事前設定のプロキシに一致すべきです。IPv4とIPv6の両方を記録します。プロキシがIPv4のみを処理する場合、システムのIPv6がもう1つの出口を形成することがあります。

WebRTC

BrowserLeaksのWebRTCテストは、リモートIP、WebRTCサポート、候補アドレス、メディアデバイスの権限を表示します。露出すべきでないローカルまたは公衆アドレスが現れないか、ブラウザ設定が無効化・置換・中継・プロキシ追従のどれか確認します。

「アドレスが現れない」ことは、WebRTC機能が必ず使えることを意味しません。ビデオ会議業務では、カメラ、マイク、リアルタイム接続もテストし、プライバシーポリシーが必要な機能を壊していないことを確認します。

DNS

ドメイン解決がプロキシ経由か、企業DNSか、ローカルネットワークかを確認します。プロキシIPが対象地域にあってもDNSリクエストが別地域から来ると、不一致になります。正確なポリシーはプロキシの種類と業務要件によります。

プロキシ切断

これは最も重要でありながら、最も見落とされがちなテストです。

環境を起動し、プロキシIPを確認します。
テストページでネットワーク状態を継続的に更新します。
プロキシを能動的に停止するか、誤った資格情報を入力します。
ページがオフラインになるか、明確な警告を出すか、ローカル出口に戻るかを観察します。
プロキシを復元した後、以前の接続が再確立されるか確認します。
時刻、ログ、スクリーンショットを保存します。

重要な業務では、静かな直接接続よりも、失敗時遮断（フェイルクローズ）や明確な警告を選ぶのが通常適切です。PurpleMarkでは、プロキシは最初に独立したリソースとして管理され、その後環境にバインドされます。切断テストでは、まずプロキシリストでそのプロキシの出口IPを確認し、停止させてから、テスト対象の環境が警告を出してオフラインのままになるか、静かにローカルネットワークへ切り替わらないかを観察します。これにより、プロキシリソースと環境のバインド関係が明確かも検証されます。

ステップ5：フィンガープリントパラメータが矛盾していないか確認する

一般的な異常な組み合わせは次のとおりです。

UAが特定のブラウザバージョンを名乗るが、実際のカーネル能力が明らかに一致しない。
OS、フォント、スクロールバー、システムコントロールが不整合。
タイムゾーン、言語、地理位置が、プロキシ地域から見て合理的な説明がない。
画面解像度がデバイスタイプに一致しない。
WebGLレンダラーとOSの組み合わせが異常。
モバイル端末を名乗りながら、デスクトップ限定の挙動を露出する。
Client HintsとUser-Agentが不一致。

すべての項目を手動で「最も珍しい」組み合わせに変えないでください。製品が提供する整合的なテンプレートを使い、業務に本当に必要な項目だけを調整します。カスタマイズのたびに変更記録を残し、ロールバックできるようにします。PurpleMarkで環境を作成する際に利用できるOS、Chromiumカーネル、UA、タイムゾーン、言語、地理位置、WebRTC、UDPの各オプションは、これらのパラメータを自己整合的に保つためのものです。テスト時は整合的な既定設定から始め、業務が必要とする項目だけを変更し、まず元の値を記録して比較・ロールバックできるようにします。

ステップ6：実際の業務互換性テストを行う

検出サイトは実際の作業の代わりにはなりません。企業自身のテストアカウントを使って以下を検証します。

ログイン、ログアウト、2段階認証。
画像、動画、ファイルのアップロード。
カメラ、マイク、WebRTC。
決済サンドボックスまたはテスト決済。
地図、タイムゾーン、ローカライズ。
拡張機能、パスワードマネージャー、クリップボード。
長時間稼働、スリープ復帰、異常終了。

ページエラー、繰り返されるCAPTCHA、パフォーマンス、リソース使用量を記録します。アカウント制限を自動的にフィンガープリントのせいにしないでください。まずプロフィール、ネットワーク、決済、コンテンツ、行動、権限、プラットフォームポリシーを切り分けます。

ステップ7：更新、復旧、退会をテストする

信頼性には、障害後の復旧も含まれます。

非本番のテスト環境を複製します。
クライアントのアップグレードとカーネル更新をシミュレートします。
Cookie、拡張機能、プロキシ、タブが保持されるか確認します。
誤削除をシミュレートし、ゴミ箱から復元します。
予備端末で環境を引き継ぎます。
エクスポートが許可されている設定と業務記録をエクスポートします。
アカウントを閉じた後のクラウドデータ削除フローを検証します。

ベンダーが「作成成功」だけを表示し、バックアップ、ロールバック、移行の質問に答えられないなら、重要な業務を担うのに適しません。PurpleMarkで検証する場合、まず誤って削除したテスト環境をゴミ箱から復元できます（ゴミ箱内のデータは一定期間保持された後、自動で削除されるため、短期的な復旧訓練には適しますが、恒久的なバックアップにはなりません）。次に、メイン端末と予備端末で同じ環境を正常に引き継げるか、設定とログイン状態が継続されるかを確認します。

ステップ8：チームの権限と監査をテストする

管理者、オペレーター、外部委託の3種類のテストメンバーを作成し、項目ごとに検証します。

誰がプロキシパスワードを見られるか。
誰がフィンガープリントとネットワーク設定を変更できるか。
誰がCookieやデータをエクスポートできるか。
誰が環境を削除・移管・共有できるか。
主要な操作がメンバー、時刻、対象を記録するか。
退職時にセッション、キー、環境アクセスを即時剥奪できるか。

多くの人が管理者パスワードを共用するのは、技術的なフィンガープリントが良好でも、信頼できる企業ソリューションとは言えません。ここでPurpleMarkのメンバー、ロール、認可グループ、操作ログが役立ちます。まず異なるタイプのメンバーに異なるロールと認可を割り当て、次に誰がプロキシパスワードを見られるか、誰がネットワーク設定を変更できるかを検証し、最後に操作ログで主要なアクションがメンバー、時刻、対象を記録したことを確認し、退職するメンバーの環境アクセス剥奪をシミュレートします。

100点の採点表

項目	点数	採点方法
同じ環境の時間的一貫性	20	5回のテストで安定項目に説明不能な跳びがない
環境間のデータ分離	15	Cookie、ストレージ、拡張機能、設定を共有しない
パラメータ整合性	15	UA、カーネル、OS、言語、タイムゾーン、GPUが妥当
ネットワークとリーク処理	20	IP、WebRTC、DNS、IPv6がポリシーに一致、切断時に静かな直結がない
実サイト互換性	10	主要フローとメディア機能が合格
更新・復旧・移行	10	アップグレード、誤削除、端末変更、エクスポートが可能
権限・ログ・剥奪	10	最小権限と退職フローが実行可能

小規模パイロットの入り口として80点を設定できますが、プロキシ切断時の直結、環境をまたぐセッション、メンバー権限を剥奪できないことなどは拒否権事項とすべきで、他の点数で相殺してはいけません。

検出結果の誤判定を避けるには？

原理の異なる少なくとも2つの検出ツールで相互確認します。
拡張機能やリソースの干渉を避けるため、検出ページを同時に大量に開きません。
同じネットワーク条件で繰り返し、一度に1つの変数だけを変えます。
「合格/不合格」の色だけでなく、生の項目を保存します。
製品、カーネル、OSのバージョンを記録します。
テストツールが更新されたら、ベースラインを再構築します。
検出サイトのプライバシーとデータ保持の通知を読みます。
テスト環境では実際の顧客バックエンドにログインしません。

よくある質問

フィンガープリント検出サイトがすべて正常でも、本番投入できますか？

できません。繰り返し起動、環境間分離、プロキシ切断、実サイト、アップグレード復旧、権限の各テストを完了し、少数の非重要アカウントでパイロットする必要があります。

Canvasハッシュが異なれば、環境分離が成功したことになりますか？

必ずしもそうではありません。ハッシュはレンダリング結果の一部しか表しません。Cookie、ローカルストレージ、拡張機能、ネットワーク、タイムゾーン、チーム共有境界を引き続き確認する必要があります。

WebRTCは完全に無効化すべきですか？

業務次第です。ビデオ会議などの機能はWebRTCを必要とします。目標は、現れるべきでないアドレスの露出を避けつつ、必要な互換性を保つことであり、すべてをオフにすることではありません。

どのくらいの頻度で再テストすべきですか？

製品やカーネルの大規模更新、OSのアップグレード、プロキシ提供者の変更、権限モデルの変更後はすぐに再テストします。安定期には少なくとも四半期に一度サンプリングし、バージョン比較を残します。

結び

アンチディテクトブラウザの信頼性を検証することは「ワントリック」ではなく、再現可能な一連の実験です。サードパーティのページは項目を観察するのに役立ちます。実際に業務で使えるかを決めるのは、時間的一貫性、環境分離、ネットワーク障害処理、パラメータ整合性、実サイト互換性、復旧と移行、チームガバナンスです。

まずベースラインを確立し、一度に1つの変数だけを変えます。緑の表示だけを見るのではなく、生の結果を保存します。しきい値に達したら非重要アカウントでパイロットし、継続的に再テストします。そうして初めて、マーケティングの主張は検証可能な技術的結論になります。開始準備ができたら、まずPurpleMark Webアプリでテスト専用の独立環境を作成し、最初のラウンドを実行できます。ローカルブラウザ機能が必要なら、ダウンロードページでインストールを完了してください。テストは特定のバージョン・端末・プロキシ・時点での性能しか反映しません。PurpleMarkも他のブラウザ環境ツールも、身元の偽装、トラフィックの水増し、大量スパムマーケティング、プラットフォーム制裁の回避に使うべきではなく、アカウントとコンテンツのコンプライアンスの代わりにはなりません。