ブラウザ指紋を確認する方法：ステップごとのプロフィール監査と重大な不整合の検出

ブラウザ指紋（browser fingerprint）は、単なる User-Agent 文字列でも、単なる IP アドレスでもありません。これは、ネットワーク、HTTP、JavaScript のシグナルの組み合わせです：IP / GEO / ASN、DNS、WebRTC、timezone、language / locale、screen resolution、Canvas fingerprint、WebGL fingerprint、AudioContext、fonts、Client Hints、そして navigator.webdriver のような automation indicators。サイトはこれらのデータを個別には見ません。相互に照合し、プロフィールが一貫していてもっともらしく見えるかを評価します。

そのため、ブラウザ指紋の確認とは「1つのチェッカーを起動して緑のチェックを確認する」ことではありません。まともな監査は短い workflow です。最初にネットワーク、次に browser environment、その後に consistency、そしてその後に修正です。BrowserLeaks は深いモジュール診断に強く、Pixelscan は consistency に関する迅速な all-in-one レポートに、AmIUnique は uniqueness/history に、Cover Your Tracks は privacy と tracking のレイヤーを示し、なぜ1つのテストだけではほとんど常に不十分なのかを説明します。

以下は、プロフィールの初回起動前と アカウントのウォームアップ 前に実行しやすい、実践的な確認順序です。この監査の主な目的は「100% の匿名性」ではなく、サービスやサイトが最初に目を付ける大きな不整合（mismatch / consistency issue）を取り除くことです。EFF は、完璧な保護は存在せず、いくつかの「プライバシー改善」は逆にブラウザをより目立たせる可能性があると別途強調しています。

5つの要点での短い答え

1. 最初にネットワークを確認してください： IP、GEO、ASN、DNS、WebRTC。ここで leak や mismatch があるなら、Canvas/WebGL の確認はまだ二次的です。
2. 次に consistency を確認してください： User-Agent、Client Hints、OS、timezone、language / locale、screen。現在は User-Agent だけでは不十分です。ブラウザは UA を縮小し、詳細の一部を Client Hints で渡すためです。
3. その後で high-entropy シグナルを見ます： Canvas、WebGL、fonts、AudioContext。「一意性」だけでなく、プロフィールが壊れて見えないか、過度に改変されていないかも見てください。
4. Automation/headless の red flags は別に確認してください： navigator.webdriver、CDP、Headless indicators、そして「偽装された」Navigator は、珍しい Canvas hash より重要なことがよくあります。
5. 変更後は毎回監査を再実行してください： あるサービスで緑の結果が出ても、別のサービスで「理想的なプロフィール」であることを意味しません。

ブラウザ指紋とは何か、そしてなぜ1つのテストでは不十分なのか

理論的な基礎が必要なら、別途 デジタル指紋とは何か の資料を見てください。以下はまさに operational なアプローチです。つまり、シグナルをどう読み、何を最初に直すべきかです。

ブラウザ指紋 vs cookie vs IP

Cookie は、サイトがブラウザに保存するデータです。削除、制限、またはブロックできます。Fingerprint は、サイトが headers、JavaScript、Web APIs から収集するブラウザとデバイスの特性の集合です。EFF は cookie tracking と browser fingerprinting を2つの異なる仕組みとして明確に区別しています。cookies はユーザーが削除すると「消えます」が、fingerprint は設定、言語、フォント、画面、ハードウェアなど、より持続的な特徴に依存します。

IP も fingerprint と混同してはいけません。IP はネットワークアドレスであり、プロフィールの完全なデジタルアイデンティティではありません。さらに、IP による地理位置情報は近似的です。MaxMind は city-level GEO を地図上の正確な地点として扱うのではなく、accuracy radius を見ることを推奨しています。それとは別に、ブラウザの Geolocation API があります。これは navigator.geolocation を通じて動作し、ユーザーの permission を必要とし、GPS や Wi-Fi を含む、より正確なデバイスシグナルを使用できます。

なぜ uniqueness だけでなく consistency も重要なのか

実用的な監査では、プロフィールがどれだけユニークかだけでなく、どれだけ整合しているかのほうが重要です。Pixelscan は自らの検査を consistency と detectability の分析として説明しています。つまり、User-Agent integrity、OS consistency、hardware parameters、timezone/language alignment、automation indicators を見ています。プロフィールは最も珍しくなくても、内部矛盾のために失敗することがあります。

状況をさらに複雑にするのが User-Agent reduction です。MDN は、対応ブラウザが UA から正確なプラットフォーム/OS バージョン、デバイスモデル、ブラウザの minor version を削除し、より詳細なデータは Sec-CH-UA-* Client Hints を通じて渡されると書いています。そのため、現在確認すべきなのは単一の User-Agent ではなく、User-Agent + Client Hints + JavaScript シグナルの組み合わせです。

サイトが相互に照合するシグナル

実際には、サイトは通常の HTTP headers（User-Agent、Accept-Language）、JavaScript シグナル（navigator.language、navigator.languages、Intl.DateTimeFormat().resolvedOptions() による timezone）、screen resolution、Canvas/WebGL rendering、AudioContext、fonts、WebRTC IP、geolocation の permission/data、さらに navigator.webdriver のような automation indicators を結び付けます。AmIUnique、BrowserLeaks、Cover Your Tracks、BrowserScan は、これらのレイヤーを異なる深さで確認しますが、扱う要素のセットはかなり重なっています。

5分でできるクイック監査：どの順番でプロフィールを確認するか

以下は、最小限の時間で最大限の効果を得られる基本的な順序です。要点は、最初のステップで DNS が漏れているのに、Canvas に20分を費やさないことです。

ステップ1. IP、GEO、ASN、DNS、WebRTC を確認する

まずは IP レイヤーから始めます。BrowserLeaks の IP ページでは、IP、country/state/city、ISP、organization、ASN/network、usage type、timezone がすぐに表示され、その下に WebRTC、DNS、TCP/IP、TLS、HTTP/2 のブロックがあります。これは、ブラウザ UI ではなく、まさにネットワークがあなたについてどんな物語を語っているかを素早く理解する方法です。

次に DNS と WebRTC を見ます。BrowserLeaks は、誤ったネットワーク設定や問題のある VPN/proxy のために DNS リクエストが ISP の DNS サーバーへ直接送られると DNS leak が発生すると説明しています。さらに、その WebRTC test は STUN リクエストがあなたの local/public IP を露出していないかを示します。Whoer もこれをチェックの中心に置いており、IP country と DNS、time zone/locale、tunneling signs を比較します。この段階では、BrowserLeaks checker、Whoer checker、および WebRTC leaks に関する個別の解説を使うのが便利です。

IP GEO と browser geolocation を混同しないでください。IP location は GeoIP データベースから来るため近似的ですが、Geolocation API は別の仕組みで、permission を求め、より正確なデバイスシグナルを使用できます。したがって、IP 上の都市が奇妙でもそれだけでは決定的ではありませんが、国、ASN、タイムゾーン、DNS ルートの不一致はすでに修正の理由になります。

ステップ2. User-Agent、OS、timezone、language、screen を確認する

次のレイヤーは browser environment check です：User-Agent、OS/platform、timezone、language / locale、screen resolution。ここで重要なのは UA reduction を覚えておくことです。MDN は、現代の UA strings は一般化されて見えることがあり、詳細の一部は Sec-CH-UA-* hints に移ることを個別に示しています。BrowserLeaks Client Hints test は、HTTP と JavaScript API を通じて何が返されているかを見るのに役立ちます。

User-Agent、navigator.platform、Client Hints、Intl.DateTimeFormat().resolvedOptions().timeZone、navigator.language / navigator.languages、Accept-Language を相互に照合してください。MDN は、navigator.languages と Accept-Language は通常同じ locale のセットを反映し、resolvedOptions() はユーザーの現在の time zone を返すと述べています。UA が「Windows」と言っているのに、platform と high-entropy hints が macOS を示していたり、言語と timezone が IP 地域と明らかに一致しない場合、それはすでに本当の不整合であり、「見た目の問題」ではありません。

ブラウザコアの新しさも別に見てください。Multilogin は、outdated browser core makes profile stand out と明記しており、browser version と emulated OS の mismatch は warnings を引き起こす可能性があるとしています。そのため、engine update や UA の手動修正の後は、このステップを繰り返すのが望ましいです。

ステップ3. Canvas、WebGL、fonts、AudioContext を確認する

次に、high-entropy シグナルへ進みます：Canvas fingerprint、WebGL fingerprint、fonts、AudioContext。BrowserLeaks は、Canvas がレンダリング差異からどのように形成されるか、そして WebGL が GPU/renderer に関するデータをどのように明らかにするかを示します。AmIUnique は Canvas、WebGL、audio info、fonts、screen などの特徴を、ブラウザの識別可能性を評価するために収集します。

しかし、ここで重要なのは「珍しさ」だけではありません。EFF は警告しています。もし指紋の1要素だけを単独で変更すると、ブラウザを目立たなくするどころか、逆により目立たせてしまう可能性があります。なぜなら、メトリクスは密接に結び付いているからです。Multilogin も似た推奨をしています。つまり、何をしているか理解している場合にのみ、fingerprint settings を深く変更すべきです。このレイヤーの文脈については、Canvas fingerprinting に関する別資料が役立ちます。

ステップ4. Automation/headless の red flags を確認する

プロフィールが automation と一緒に使われている、または自動化されているように見える場合は、個別の bot-detection layer を起動します。MDN は navigator.webdriver を、document が WebDriver によって制御されていることを示す標準的な兆候として説明しており、Chrome では --enable-automation または --headless が使われると true になります。BrowserScan はさらに WebDriver、CDP、Headless Chrome、deceptive Navigator を確認し、Pixelscan は automation indicators を別ブロックとして表示します。

実際的には意味することは1つです。まず network problems を修正し、その次に automation flags、その後で uniqueness の見栄えの良い指標を見るべきです。大半の実運用のチェックでは、サイトはあなたの Canvas hash が「皆と違う」ことよりも、webdriver、DNS leak、または UA/OS mismatch に先に反応する可能性が高いです。これは、サービスが問題をどのようにランク付けし、強調するかから導かれる実践的な結論です。

ステップ5. 変更後にテストを繰り返す

修正のたびに、同じ順序で監査をやり直してください：network → fingerprint → consistency → fixes。これは形式的なものではありません。MDN は、Client Hints は Accept-CH を通じて要求され、その後は特定の origin に対する現在の browsing session に保存されることがあると述べています。さらに、Cover Your Tracks と AmIUnique は research cookies を使って再訪問を関連付け、fingerprint が時間とともにどう変わるかを調べます。そのため、再テストはプロフィールの再起動後に、必要であれば clean environment で行うのがよいです。

ブラウザ指紋の確認にどのサービスを使うべきか

1つのサービスは完全な確認と同義ではありません。通常の監査では、少なくとも2種類のツールを組み合わせます。1つは network-oriented、もう1つは consistency-oriented です。BrowserLeaks は低レベルのモジュールを提供し、Pixelscan は consistency に関する単一レポート、AmIUnique は uniqueness/history、Cover Your Tracks は tracker/privacy の視点、iphey、Whoer、BrowserScan は追加の迅速なレイヤーとして有効です。

表1. サービス比較

BrowserLeaks — 深いモジュール診断のために

BrowserLeaks は、プロフィールが どのレイヤーで 壊れているのかを理解したいときの最初の最良の選択です：network、JavaScript、rendering、または transport。IP/GEO/ASN/usage type、DNS、WebRTC、Canvas、WebGL、fonts、Client Hints、さらには TLS/HTTP2/TCP/IP fingerprints まで表示します。Undetectable のエコシステムで同様のシナリオが必要なら、BrowserLeaks checker から始めてください。

Pixelscan — 迅速な all-in-one 監査のために

Pixelscan は、迅速な first pass として、または BrowserLeaks 後の second opinion として便利です。サービス自身の manifest では、user-agent integrity、operating system consistency、Canvas/WebGL and rendering signals、hardware parameters、timezone/language alignment、proxy/DNS behavior、automation indicators を分析すると書いており、「Windows UA だが macOS シグナル」といった mismatches を即座に強調します。このシナリオには Pixelscan checker を使用してください。

AmIUnique — fingerprint の一意性と履歴を評価するために

AmIUnique は、質問が「なぜ DNS が漏れるのか」ではなく、「私はどれほど識別可能か」という場合に必要です。このプロジェクトは browser fingerprints の多様性を研究し、広範な headers と JS シグナルを収集し、research cookie を通じて再訪問を関連付け、fingerprint が時間とともにどう変わるかの履歴を表示します。すぐに使えるように、AmIUnique checker を手元に置いてください。

Cover Your Tracks（旧 Panopticlick）— privacy/fingerprint の教育のために

Cover Your Tracks は、歴史的なサービス Panopticlick の現在の名称です。EFF は2020年に名称を変更し、「fingerprinting が存在する」という単純なデモから、tracking/privacy trade-offs をより分かりやすく説明する方向へ重点を移しました。サービスは、trackers がブラウザをどう見ているかを示し、detailed view では System Fonts、Language、AudioContext といったメトリクスを表示します。Undetectable 内で起動するには、Panopticlick / Cover Your Tracks checker を使ってください。

補足：iphey、Whoer、BrowserScan

追加ツールとしては、browser、location、IP、hardware、software による「trustworthy / suspicious / unreliable」の迅速な heuristic score が必要なら iphey checker を、time zone と locale の比較を伴う instant IP/DNS/privacy-check が必要なら Whoer checker を手元に置いてください。BrowserScan は独立した bot-detection layer として有用で、WebDriver、CDP、Headless Chrome、deceptive Navigator properties を分析します。

結果の読み方：本当に重大な red flags は何か

以下は、問題の実用的な階層です。これは BrowserLeaks、Pixelscan、AmIUnique、Cover Your Tracks、Whoer、そして Multilogin の推奨が実際に何を強調するかから導かれた、編集上の作業スキームです。つまり、まず consistency と network trust を壊すものを修正し、単に uniqueness score を上げるものではないということです。

表2. 問題診断

IP/GEO mismatch

IP mismatch は単に「都市が違う」という意味ではありません。BrowserLeaks の IP ページでは、country、ISP、ASN/network、usage type が重要です。Whoer はさらに IP country と DNS、time zone/locale、tunneling signs を比較します。実際には、正確な city-level GEO よりも 国 + ASN + timezone + ネットワークタイプ の組み合わせのほうが重要です。

最初の修正はほとんどの場合 network-side です。ブラウザで последствия を隠すのではなく、proxy または proxy type を変更してください。タスクが IP タイプや ASN の評判に敏感であれば、mobile vs residential proxies の資料でシナリオを個別に比較してください。そして geolocation の手動偽装から始めないでください。Multilogin は、custom geolocation が geolocation/IP mismatch を作り出す可能性があると明確に警告しています。

DNS/WebRTC leaks

DNS/WebRTC leaks は重大な red flag です。なぜなら、外部 IP が「正しく」見えても、実際のルーティングを明らかにする可能性があるからです。BrowserLeaks は、誤った設定では DNS リクエストが直接 ISP DNS に送られる可能性があると書いており、その WebRTC test は STUN を通じた local/public IP exposure を示します。Whoer も、DNS、WebRTC、IP leaks をプライバシー/マスキングの基本問題として扱っています。

ここでの修正順序は常に同じです：DNS path → WebRTC mode → retest。WebRTC や DNS がまだ通らないなら、作業セッションやましてウォームアップに進んではいけません。まず connection layer を正常化してください。詳細は WebRTC leaks からどう保護するか の解説にあります。

User-Agent と OS の不一致

UA/OS mismatch は、最も頻繁な operational 問題の1つです。Pixelscan は、Windows user-agent が macOS signals と競合する例を直接挙げています。Multilogin は、古いコアがプロフィールを目立たせ、browser version と emulated OS の mismatch が warnings を引き起こす可能性があると別途述べています。UA reduction を考えると、比較すべきなのは UA 文字列だけでなく Client Hints もです。

Timezone/language mismatch

Timezone と language は小さなシグナルですが、プロフィールの他の部分と矛盾したときに大きな意味を持ちます。MDN は、resolvedOptions() が現在の time zone を返し、navigator.languages と Accept-Language は通常同じ locale のセットを反映すると述べています。Multilogin は、サイトがしばしば IP-derived timezone と JavaScript-derived regional settings を比較すると指摘しています。

最初の修正は、何を真実のソースとするかに依存します。proxy が正しく選ばれていて、ブラウザの locale/timezone が違うなら、ブラウザを合わせます。locale が意図的かつ安定していて、IP 地域のほうが変なら、proxy を変更します。best results のためには、languages は通常 proxy/task locale に対応しているべきであり、ランダムなセットのままではいけません。

Canvas/WebGL anomalies

Canvas/WebGL anomalies は無視できませんが、最初の 原因であることはまれです。BrowserLeaks は、Canvas と WebGL fingerprints がレンダリング差異から構築されることを示し、MDN は WEBGL_debug_renderer_info がグラフィックスタックの vendor/renderer を明らかにする可能性があると述べています。同時に、EFF は警告しています。1つの fingerprint シグナルだけを単独で変更すると、ブラウザをより目立たせてしまう可能性があります。

そのため、「珍しい hash」よりも危険なのは、完全に無効化された、壊れた、または ノイズが強すぎる rendering です。Multilogin は、totally unique or altered graphics fingerprints に多くの人気サイトが悪く反応する一方で、実際の Canvas/AudioContext outputs は多くの似たデバイスの中に自然に混ざることが多いと明確に書いています。

「ランダムすぎる」プロフィールと automation flags

Automation indicators はより解釈しやすいです。navigator.webdriver が見える、または BrowserScan/Pixelscan が CDP/headless/deceptive Navigator traces を検出するなら、それは見た目の問題ではなく、実際の red flag です。MDN は navigator.webdriver を automation/headless launch flags と直接結び付けています。

一方で、TCP/IP fingerprint は最初の確認で過大評価すべきではありません。Multilogin は、proxy が network data を再パッケージ化するため、passive OS fingerprint が実際の OS と一致しないことがあり、多くのサイトはこの違いを珍しくないため無視すると述べています。これを最初の作り直し理由としてではなく、second-pass nuance として確認してください。

なぜ異なるサービスが異なる結果を表示するのか

確認の深さが異なる

最初の説明は、深さが異なることです。BrowserLeaks は個別モジュールの集合であり、Pixelscan は複数レイヤーを1つの actionable report にまとめようとし、AmIUnique は identifiability と history に集中し、Cover Your Tracks は tracker/privacy view に集中し、BrowserScan は bot-detection シグナルに重みを置きます。ツールが異なる質問をしているなら、答えも異なります。

手法とヒューリスティクスが異なる

2つ目は、手法の違いです。MDN は Client Hints を low-entropy と high-entropy に分けており、いくつかの hints は Accept-CH を通じた opt-in を必要とします。AmIUnique は fingerprint を研究用データセットと比較し、Cover Your Tracks は tracking/fingerprinting からの保護を評価し、Pixelscan は内部 consistency に重点を置きます。したがって、2つのサービスが同じプロフィールを見ても、異なるリスクの断面を分析している可能性があります。

あるサービスで「緑」でも「理想的なプロフィール」ではない理由

ある checker で緑の結果が出ても、そのプロフィールがどこでも理想的であることを意味しません。uniqueness-oriented なサービスでは問題なく見えても DNS/WebRTC で漏れている場合もあります。privacy feedback は良くても automation スタックには弱く見える場合もあります。all-in-one scan ではクリーンに見えても、低優先度の transport oddity を持つ場合もあります。そのため、実務上の最低ラインは、1つの network-oriented checker と1つの consistency-oriented checker です。

プロフィールが監査を通らない場合、何を最初に修正すべきか

プロフィールが audit を通らない場合、すべてを一度に直そうとしないでください。上から下へ進むほうが速いです：connection layer → consistency layer → high-entropy layer → rebuild。この順序は、structured checkers が問題を表示する方法とも、mismatch に関する実用的な推奨とも一致しています。

プロキシと sticky sessions

まずは proxy quality とセッションの安定性から始めてください。もし proxy IP が作業セッションの途中で変わると、timezone/geolocation/WebRTC alignment が「ずれ」始め、原因ではなく症状を追いかけることになります。Multilogin は、mid-session proxy IP change の後にシステムが WebRTC と geolocation を調整しなければならないシナリオを説明しています。BrowserLeaks と Whoer も、IP/DNS leak の挙動が基盤であり、細部ではないことを示しています。そのため、first run と アカウントのウォームアップ の開始時には、1セッションにつき1つの安定したネットワークの物語を維持し、proxy を変更するたびにプロフィールを retest するのが望ましいです。ネットワークタイプと ASN にまさに問題がある場合は、mobile vs residential proxies の資料で選択肢を比較してください。

プロフィールの分離

プロフィールは isolation の状態で監査してください。不要な拡張なし、過去の実験なし、予測可能な permissions の状態です。EFF は、privacy add-ons や珍しい保護策自体が fingerprint の一部になり得ると別途書いています。Multilogin は、same-origin policy を思い出させます。サイトは他ドメインの cookies を見ません。実用的な結論は単純です。独立したプロフィール、余計なものは最小限、再現可能な設定です。

ブラウザコアのバージョンと headers

network layer がクリーンなら、browser core と headers に進みます。古いコア、UA の手動置換の残骸、browser version と emulated OS の競合は、エキゾチックな Canvas 問題よりも頻繁に warnings を引き起こします。ここでの推奨は直接的です。最新のコアを維持し、User-Agent が実際のブラウザバージョンと申告された OS に対応していることを確認してください。

ランダム化をやりすぎない

randomization をやりすぎないでください。EFF は、他の要素から切り離して1つの fingerprint 要素だけを変えることを明確に推奨していません。なぜなら、メトリクスは相互に関連しているからです。Multilogin も、結果を理解せずに深い fingerprint settings を触るべきではないと警告しています。実際には、安定していて整合的な defaults は、攻撃的な手動の「偽装」よりほとんど常に優れています。

いつプロフィールをゼロから再作成すべきか

基本的な修正の後も構造的な矛盾が戻ってくる場合は、プロフィールを再作成してください。たとえば、proxy はすでにクリーンなのに UA/OS がまだ食い違う、timezone/language を手動でパッチし続けなければならない、permissions や extensions が結果を汚し続ける、automation flags が relaunch 後に再び現れる、といった場合です。これは実践的な結論ですが、EFF や vendor docs が示す同じ考えから論理的に導かれます。つまり、fingerprint メトリクスは相互に関連しており、「プロフィールの物語」が一貫性を失ったときは、終わりのない patching より rebuild のほうが速いことが多いのです。

プロフィールを実運用で起動する前のチェックリスト

以下は、first run 前や アカウントのウォームアップ 前に保存しておくと便利な短いリストです。

プロフィール起動前のチェックリスト

• IP country、ASN、usage type がタスクに適している；city-level GEO を正確な地理として受け取らない。
• DNS servers が ISP 経由のルートを露出しておらず、WebRTC が本物の local/public IP を表示しない。
• User-Agent、Client Hints、OS/platform が同じ物語を語っている。
• Accept-Language、navigator.language(s)、timezone が proxy/task locale に対応している。
• Screen resolution がデバイスとチームに対して現実的に見える。
• Canvas/WebGL/AudioContext が壊れておらず、理由なく無効化されておらず、過度に「ノイズだらけ」に見えない。
• automation がシナリオの一部でない場合、navigator.webdriver、CDP、headless flags が存在しない。
• Browser core が最新で、version と OS の mismatch が解消されている。
• Geolocation API の動作が意図的であり、prompt/allow/block が IP-story と矛盾していない。
• 各変更後に、少なくとも1つの network checker と1つの consistency checker を再実行する。

いつ通常のブラウザで十分で、いつ antidetect が必要か

通常のブラウザで十分なことはよくあります。タスクが単純な場合です。たとえば、自分の IP/DNS/WebRTC を見る、サイトが headers で何を見ているかを理解する、数個の browser signals を素早く比較する、あるいは fingerprinting がどう機能するかを理解するだけなら十分です。このような one-off の確認には、BrowserLeaks、Cover Your Tracks、AmIUnique、iphey、Whoer で足ります。

Antidetect が意味を持つのは、単発テストではなく、再現可能な作業フローが必要な場合です。つまり、複数の分離されたプロフィール、それぞれの cookies、language、timezone、proxy、launch parameters、さらにプロフィールの作成、起動、更新、終了のための API/automation がある場合です。Undetectable API のドキュメントには、lifecycle のメソッドや、proxy、language、cookies、timezone のようなパラメータが直接記述されています。製品アップデートでは、プロフィール起動前の proxy checks や headless/background operation も別途言及されています。

実用的なルートは次の通りです。まず BrowserLeaks checker、Pixelscan checker、AmIUnique checker、Panopticlick / Cover Your Tracks checker で setup を確認し、必要なら iphey と Whoer で補強してください。必要なのが単発のテストではなく、プロフィール、cookies、proxy、automation を伴う継続的な workflow であれば、Undetectable のダウンロード に進み、その後 料金プラン を確認してください。そしてその場合でも audit は必須です。どの製品も、それだけで mismatch が存在しないことを保証するものではありません。

FAQ

1. browser fingerprint とは何ですか？

Browser fingerprint は、サイトが HTTP headers、JavaScript、Web APIs から収集するブラウザとデバイスの特性のセットで、1つのブラウザを別のブラウザと区別するために使われます。これには UA、言語、timezone、screen、fonts、Canvas/WebGL、audio などのシグナルが含まれます。これは cookie とも、IP とも同じではありません。

2. なぜ BrowserLeaks と Pixelscan は異なる結果を表示することがあるのですか？

彼らが解決しているタスクが異なるからです。BrowserLeaks はモジュール型の低レベルテスト群であり、Pixelscan は detectability、internal mismatch、automation indicators に重点を置いた all-in-one consistency report です。同じプロフィールを同じように評価する必要はありません。なぜなら、見ているレイヤーも使っているヒューリスティクスも異なるからです。

3. cookie を削除するとブラウザ指紋は変わりますか？

通常は変わりません。Cookies と fingerprint は別の仕組みです。cookie を削除するとサイトに保存された識別子は消えますが、language、timezone、screen、fonts、GPU、WebRTC behavior は変わりません。同時に、Cover Your Tracks や AmIUnique のような一部のサービスは、繰り返しテストを関連付けて fingerprint が時間とともにどう変わるかを研究するために、自ら research cookies を使います。

4. proxy と fingerprint のどちらが重要ですか？

開始時には proxy と network layer が重要です。DNS leak、WebRTC leak、奇妙な ASN、または IP/timezone mismatch があるなら、Canvas/WebGL の細かな調整ではプロフィールを救えません。最初にネットワーク、その後で browser fingerprint の consistency です。

5. どのくらいの頻度でプロフィールを再確認すべきですか？

最低限、初回起動前、proxy の変更後、browser core の更新後、UA/language/timezone/geolocation の手動修正後、automation/headless 設定の変更後です。さらに、サービスとメトリクスは発展し続け、一部のシグナルは現在のセッションと具体的な origin に依存するため、定期的に監査に戻る意味があります。

6. WebRTC または DNS leak が通らない場合はどうすればよいですか？

停止して connection layer を修正してください：DNS route、WebRTC mode、proxy quality、session stability です。その後でのみ再テストします。BrowserLeaks と Whoer は DNS/WebRTC leaks を基本的な問題のリストに直接含めており、Multilogin も WebRTC と IP-story を同期させる重要性を別途示しています。

7. なぜプロフィールは1つのテストでは通るのに、別のテストでは落ちるのですか？

異なる checkers は、異なる深さを確認し、優先順位も異なるからです。あるものは uniqueness/history を見て、別のものは privacy protection を、3つ目は internal consistency を、4つ目は automation traces を見ます。これは正常な状況です。だからこそ、完全な監査は常に複数のサービスで構成されます。

Undetectable Team 検出防止の専門家