はじめに(この記事で分かること)#
VPNにつないで確認サイトを開き、表示されたIPアドレスがVPNの出口に変わっているのを見て安心する。多くの人の「確認」はここで終わる。だが、その画面が保証しているのは「今この瞬間、このブラウザからそのサイトへの通信がVPNの出口から届いた」ということだけだ。DNSの問い合わせはどこへ出ているのか。IPv6は。WebRTCは。ブラウザそのものが一台だけの特徴を持っていないか。投稿した写真に撮影場所が残っていないか。
この記事は、それらを一本の手順にまとめた点検表である。個々の仕組みと対策は、DNSリーク、WebRTCリーク、キルスイッチ、フィンガープリント、カンパートメント化の各記事で扱った。ここでは「何を、どの順で、どの道具で確かめ、結果をどう読むか」に絞る。紹介する確認サイトは、運営者、測っているもの、データの扱いを各サイトの公式ページで2026-11-08に確認し、VPN事業者が運営しているかどうかも書いた。全項目に合格しても匿名になったわけではない。点検できない層があることは、最後にまとめて書く。
前提: 脅威モデルの整理#
脅威モデル入門では、隠す相手をISP、プラットフォーム、広告網・データブローカー、法執行機関、標的型攻撃者の5種類に分けた。自己点検で分かるのは、このうち「自分の端末から外に何が出ているか」と「サイトの側から自分がどう見えるか」の二つに限られる。
接続・DNS・IPv6の点検は、主にISPと同じネットワークにいる第三者に対して意味を持つ。トンネルの外に出た問い合わせや通信は、彼らに見える。WebRTC・ブラウザの指紋・ファイルのメタデータの点検は、プラットフォームと広告網に対して意味を持つ。彼らが受け取るのは、ページ上のスクリプトが読み取れる値と、アップロードされたファイルそのものだからだ。復旧経路と公開情報の点検は、OSINTで身元を探る標的型の相手と、プラットフォームに記録の提出を求める法執行機関の両方にかかわる。
逆に、どの点検でも見えないものがある。VPN事業者やプラットフォームのサーバーに残っている記録、ログインしたアカウント同士のつながり、文体や活動時間帯、通信の時刻の相関、端末そのものの侵害だ。点検は「自分の側から見える範囲」の確認であって、相手の手元にあるものを確かめる手段ではない。
点検の順序#
点検は外側の層から内側へ進める。外側の層が漏れていれば、内側の点検は意味を失うからだ。実IPがWebRTCで渡っているなら、ブラウザの指紋を整えても、サイトは本物の回線の番号を手にしている。逆に、IPとDNSがきれいでも、匿名のつもりのアカウントの再設定先が実名のメールアドレスなら、サービス事業者の記録の上では二つの区画がつながっている。
| 順 | 層 | 確かめること | 主な道具 | 詳しい記事 |
|---|---|---|---|---|
| 1 | 接続 | 外から見えるIPがVPNの出口か。切れた瞬間に実IPが出ないか | curl、am.i.mullvad.net、ipleak.net | キルスイッチ |
| 2 | DNS | 名前解決の問い合わせがトンネルの外に出ていないか | resolvectl、tcpdump、確認サイト | DNSリーク |
| 3 | WebRTC | ブラウザが実IPやLANのアドレスを候補として渡していないか | BrowserLeaks、ipleak.net | WebRTCリーク |
| 4 | IPv6 | IPv4だけトンネルに通し、IPv6が素通しになっていないか | ip、curl -6 | 本記事 |
| 5 | ブラウザの指紋 | ブラウザの特徴がどれだけ珍しいか | Cover Your Tracks、AmIUnique、BrowserLeaks | ブラウザフィンガープリント |
| 6 | メタデータ | 写真や文書に位置・端末名・作成者が残っていないか | exiftool、mat2、スマホの共有設定 | ソフトウェアの基本構成 |
| 7 | 復旧経路 | 匿名アカウントの再設定先が実名の区画を指していないか | 各サービスのアカウント設定 | アカウント復旧経路 |
| 8 | 公開情報 | 自分の名前やハンドルで何が見つかるか | 検索、Results about you、Have I Been Pwned | OSINTと自己監査 |
始める前に一つだけ準備がある。VPNを切った状態の自宅回線の公開IPアドレスを控えておくことだ。WebRTCの記事の手順と同じで、これがないと、後で確認サイトに表示された番号が「漏れた実IP」なのか「VPNの出口」なのかを見分けられない。ルーターの管理画面にWAN側のアドレスが表示される機種なら、そこで控えれば確認サイトに実IPを見せずに済む。
接続・DNS・WebRTC・IPv6#
確認サイトは誰が運営しているか#
ブラウザで開く確認サイトは手軽だが、使う前に運営者を知っておきたい。確認サイトを開くことは、自分の今のIPアドレスとブラウザの情報をその運営者に渡すことでもあるからだ。代表的なものを、各サイトの公式ページで確認できた範囲で並べる。
| 確認サイト | 運営者・利害関係 | 主に測るもの(サイト上の記載) | データの扱い(サイト上の記載) |
|---|---|---|---|
| Mullvad Connection check(mullvad.net/check) | VPN事業者のMullvad VPN AB | VPN接続の確認、DNSリーク、WebRTCリーク(ページの説明文)。位置の判定にMaxMindのGeoLite2を使うと表記 | 確認ページ上に記録の扱いの記述は見当たらない |
| ipleak.net | VPN事業者のAirVPN(ページ下部に「powered by」とAirVPNのロゴ) | ブラウザ既定と代替経路での公開IP、WebRTC、DNSの問い合わせ元、トレントクライアントが報告するアドレス、IPとブラウザの位置情報、AirVPNのアドレスかどうか | ページ上に記録・保存期間の記述は見当たらない |
| BrowserLeaks | サイト上に運営者の名義はない(連絡先はcontact@browserleaks.com) | IP、WebRTC、Canvas、WebGL、フォント、TLSクライアントなど、項目別の確認ページ | 「個人データを収集せず、指紋を保存せず、必須でないCookieを置かない」と記載。自己申告 |
Mullvadとipleak.netは、どちらもVPN事業者が運営している。確認ツールとしての動作に問題があるという意味ではないが、自社の製品を勧める動機を持ちうる立場にあることは割り引いて使いたい(LamerzはMullvadとAirVPNのレビューを載せているが、どちらともアフィリエイト契約はない)。BrowserLeaksは運営者が分からない代わりに利害関係も見えない。どれを使っても、IPアドレスを見せるという点は同じだ。
1. 接続: 表示されるIPと、切れた瞬間#
最初の確認は、ブラウザを使わずにコマンドで済ませられる。Mullvadが提供するam.i.mullvad.netは、問い合わせてきたIPアドレスを返す。末尾を/jsonにすると、IPのほかに組織名、Mullvadの出口かどうか(mullvad_exit_ip)などの項目が返る。
curl -4 -s https://am.i.mullvad.net/json
curl -6 -s --max-time 5 https://am.i.mullvad.net/json || echo "IPv6: 接続なし"
ipとorganizationの欄が、控えておいた自宅回線ではなくVPN事業者のものになっていれば、少なくともこのコマンドの通信はトンネルを通っている。ここもMullvadに自分のIPを見せる行為だという点は、ブラウザの確認サイトと変わらない。
次に、わざと切る。表示が正しいのは、トンネルがつながっている間だけだ。キルスイッチの記事の「自分で切って検証する」の手順どおりに、物理インターフェースでtcpdumpを動かしながら、1秒ごとにIPv4とIPv6の表示を記録し、Wi-Fiの切断と復帰、トンネルの手動停止、アプリの終了、再起動直後といった場面を一つずつ再現する。実IPが一度でも表示された場面が、今の設定で塞げていない隙間だ。観測するのは自分の端末と自分の回線に限る。
2. DNS: 設定とパケットの両方で見る#
DNSは、確認サイトの表示とOSの設定がずれやすい層だ。手順はDNSリークの記事に沿う。Ubuntu 26.04なら、まずresolvectl statusでVPN側のインターフェースに~.が付いているか、物理インターフェースに検索ドメインが残っていないかを見る。そのうえで、VPN接続中に物理インターフェースで53番と853番を観測する。
resolvectl status
sudo tcpdump -n -i wlp2s0 'port 53 or port 853'
何も流れなければ、平文のDNSとDNS over TLSは物理回線に出ていない。確認サイト(Mullvadの確認ページやipleak.net)では、表示されたDNSサーバーの組織名が契約しているISPになっていないかを見る。確認サイトが調べるのはそのブラウザの名前解決の経路だけで、ブラウザがDoHを使っていればOS側の漏れは結果に出ない。ブラウザ以外のアプリの問い合わせはtcpdumpでしか見えない。
3. WebRTC: 自宅のアドレスが候補に入っていないか#
WebRTCは、ブラウザが通話のために自分のアドレスの候補を集め、ページに渡す仕組みだ。WebRTCリークの記事の手順で、VPNを切った状態とつないだ状態でBrowserLeaksのWebRTC Leak Testかipleak.netを見比べる。読み方は三つに分かれる。VPN接続中のWebRTC欄に、控えておいた自宅のアドレスが出ていれば、公開アドレスの漏れだ。192.168.や10.で始まるアドレスが出ていれば、LANのアドレスが隠されずに渡っている。.localで終わる名前なら、mDNSで隠されている状態で、それ自体は公開アドレスの漏れではない。
ブラウザ拡張型のVPNやプロキシを使っている場合に自宅のアドレスが出やすいことと、カメラやマイクを許可したサイトでは制限が外れるため、許可のない確認サイトでは再現されないことは、同記事に書いたとおりだ。
4. IPv6: トンネルが運ばない経路#
IPv6は、上の三つのどれにも紛れ込む。VPNがIPv4しか運ばない設定で、回線側にIPv6がある場合、IPv4の表示はVPNのままでも、IPv6の通信は実回線から出ていることがある。確認には、端末にIPv6のグローバルアドレスと既定経路があるかを見ればよい。
ip -br addr
ip -6 route show default
ipの-brは、Ubuntu 26.04のip(8)(iproute2 6.19.0)で、基本情報だけを表形式で出すオプションとして説明されている。物理インターフェース(wlp2s0など)に2や3で始まるIPv6アドレスが付き、IPv6の既定経路が物理インターフェースを向いているなら、IPv6の通信はトンネルの外に出られる状態だ。前の手順のcurl -6が実回線のIPv6を返せば、それが確認になる。対処の方向は、VPNのアプリでIPv6をトンネルに通すか、OS側でIPv6を止めるかのどちらかになる。MullvadのヘルプもLinuxで確認ツールにIPv6のDNSアドレスが出た場合について、アプリでIPv6を有効にするか、Linux側でIPv6を無効にするよう案内している(DNSリークの記事を参照)。
Tor経由で点検する意味と、その限界#
確認サイトをTor Browserで開くと、サイトに見えるのはTorの出口ノードのアドレスになる。Tor Projectの確認ページ(check.torproject.org)は、Torを使っていない接続に対して「Sorry. You are not using Tor.」と表示し、見えているIPアドレスを並べて示す。Tor Browserを使う人にとって、まずここで経路がTorであることを確かめるのは意味がある。
Tor経由で確認サイトを開くことには、もう一つの利点がある。確認サイトの運営者に、自宅のIPもVPNの出口も見せずに済むことだ。VPN事業者が運営する確認サイトを、そのVPN事業者とは別の事業者のVPN越しに使うことへのためらいがあるなら、指紋やメタデータの確認はTor Browserで開くという選択がある。
ただし、Tor Browserで開いた確認サイトが調べているのはTor Browserの経路だけだ。端末全体のVPNのDNSやIPv6、ほかのブラウザのWebRTCが漏れていても、Tor Browserの結果には出ない。Tor BrowserはWebRTCを既定で無効にしているので、WebRTCの欄が空になるのも当然で、ほかのブラウザの安全を意味しない。VPNの点検はVPNを使っているブラウザやコマンドで、Tor Browserの点検はTor Browserで、と経路ごとに分けて行う。
自分のノードとローカルでできる確認#
第三者の確認サイトを使わずに済む方法もある。自分でVPSを借りてWireGuardの中継やWebサーバーを動かしているなら(SSHとWireGuardの踏み台など)、サーバー側から見た自分の姿を確かめられる。wg(8)のshowは、インターフェースの実行時の情報を表示し、endpointsを指定すれば各ピアのエンドポイントを出す。
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes
ここに出る自分の端末のエンドポイントが、そのサーバーの記録に残る自分の接続元だ。VPN越しにつないでいるつもりなら、VPN事業者の出口のアドレスが出ているはずで、自宅の回線のアドレスが出ていれば、その中継の手前でVPNが効いていない。Webサーバーを動かしているなら、アクセスログに残った自分のアクセスの送信元も同じ確かめ方になる。自分のサーバーのログは、押収や侵害で第三者の手に渡りうる記録でもあるので、確認が終わったら残す期間を決めておきたい。
ローカルでの確認の基本は、ここまでに出てきたtcpdumpだ。確認サイトの表示は「サイトに届いたもの」、tcpdumpの表示は「端末から出ていったもの」で、両方を見て初めて漏れの場所が分かる。
ブラウザの指紋#
Cover Your Tracksの結果をどう読むか#
EFFのCover Your Tracksは、2010年に「Panopticlick」として始まり、2020年に今の名前で作り直された(同サイトのAboutページ)。トップページは、トラッカーからブラウザがどう見えるかを示すサイトだと説明している。テストは二つの部分に分かれる。一つは、追跡型の広告や見えないトラッカーを模した読み込みを試し、ブラウザがそれを止めるかを見る部分。もう一つが指紋の測定である。
指紋の結果は、2026-11-08にテストを実行した画面では次の形で表示された。ブラウザの指紋が「過去45日間にテストされたN件の中で一意に見える」かどうか。指紋が少なくとも何ビットの識別情報を持つか。そして項目ごとに、「識別情報のビット数」と「何台に1台のブラウザがこの値を持つか」。項目はUser-Agent、タイムゾーン、画面サイズ、フォント、CanvasとWebGLのハッシュ、AudioContextなどだ。同じ画面には、追跡の技術は複雑で変化し続けるため、Cover Your Tracksはあらゆる形の追跡と防御を測るものではない、という注記がある。
読み方の要点は三つある。
一つ目に、「一意」の比較対象は、そのサイトで最近テストを受けたブラウザの集団である。インターネット全体の利用者ではない。EFFの元の論文(Peter Eckersley「How Unique Is Your Web Browser?」、2010年)は、サンプルを「プライバシーを意識する利用者」と書いたうえで、ブラウザの83.6%が一意な指紋を持ち、指紋の分布のエントロピーは少なくとも18.1ビットだったと報告している。この数字は2010年当時、FlashやJavaのプラグインがあった時代の、確認サイトを訪れた人の集団での値で、今のブラウザ一般に当てはめることはできない。
二つ目に、普通のブラウザで「一意」と出るのは珍しくない。問題は、その指紋が時間をまたいで安定しているかどうかだ。Cover Your TracksのLearnページは、Braveの方式を、トラッカーが時間をまたいで同じ人だと分からないよう指紋をランダム化するものとして説明し、Tor Browserを「全員が同じように見える」方向の、現在もっとも現実的な防御として挙げている。ランダム化するブラウザでは、テストのたびに一意と出ても、次のテストで別の値になっていれば、指紋は再訪者の目印として働きにくい(ここでの評価は筆者の読み)。
三つ目に、項目ごとの数字を見て一つずつ「よくある値」に合わせようとしないこと。同じLearnページは、各項目でもっとも一般的な値に合わせようとすると、項目同士の組み合わせによって、かえってブラウザが識別しやすくなりうると警告している。Tor Projectのサポートページも、Tor Browserの利用者を完全に同一にするのは事実上不可能で、目標は各項目の区別可能な「バケツ」の数を減らすことだと書いている。指紋の点検で読者が取れる行動は、設定の微調整ではなく、どの戦略のブラウザを使うかの選択だ。この判断はブラウザフィンガープリントの記事で扱う。
データの扱いについて、Cover Your Tracksのプライバシーページは、IPアドレスを記録せず、定期的に捨てる鍵で計算したハッシュに置き換えると書いている。一方で、テストのデータセットは無期限に保持し、ブラウザの特徴がどれだけ変わるかを調べるために3か月残るCookieを置き、データセットを研究協力者と共有することがあるとしている。テストを受けることは、EFFの指紋データベースに自分のブラウザの特徴を一件加えることでもある。
AmIUniqueとBrowserLeaks#
AmIUniqueは、ブラウザの指紋の多様性を調べ、開発者が防御を設計するためのデータを提供することを目的に掲げる研究サイトだ。連絡先はフランスのリール大学のドメイン(univ-lille.fr)のアドレスと同国の住所で、運営機関の名称はトップページとFAQには書かれていない。指紋を見るボタンを押すと、指紋を収集し、4か月間有効なCookieを置くと明記している。集める項目はHTTPヘッダー、タイムゾーン、画面、CanvasとWebGLの描画、フォントの一覧などで、Cover Your Tracksと大きくは変わらない。
BrowserLeaksは、一つの数字にまとめず、Canvas、WebGL、フォント、TLSなどの項目を別々のページで見せる。どの項目が自分の環境で目立っているかを知るのには向くが、「何台に1台」のような比較の数字は出ない。どのサイトの結果も、そのサイトの測り方と、そのサイトを訪れた人の集団に依存している点は同じだ。
ファイルとアカウント#
写真と文書のメタデータ#
通信の層をすべて整えても、アップロードしたファイルが撮影場所や作成者の名前を運ぶことがある。ここはローカルで確実に確かめられる層だ。Ubuntu 26.04では、ExifToolはlibimage-exiftool-perl(13.50)、mat2はmat2(0.14.0)のパッケージで入る。
まず、何が入っているかを見る。
exiftool -a -G1 -s photo.jpg
exiftool -a -G1 -s photo.jpg | grep -i gps
exiftool(1p)によれば、-aは同じ名前のタグも重複して表示し、-G1は各タグのグループ名を付け、-sは説明の代わりにタグ名を出す。GPSの欄に緯度・経度があれば、そのファイルは撮影場所を運んでいる。
除去には二つの道具がある。ExifToolでは、manページの例どおりexiftool -all= photo.jpgで画像からすべてのメタ情報を消す。位置情報だけを消すなら-gps:all=を使う。既定では元のファイルがphoto.jpg_originalという名前で残るので、確認が済んだら元ファイルの扱いを決める。manページは注意点もいくつか書いている。消せないグループがあること、JPEGのAPP14「Adobe」グループは画像の見た目に影響するため-All=でも既定では残ること、メーカー固有の情報が変換に必要なRAW形式(DNGを除く)にはこの操作をすべきでないこと。そしてPDFについては、ExifToolによる変更は元の情報を実際には消さずに追記する形なので元に戻せてしまい、「ExifToolだけでPDFのメタデータを安全に編集することはできない」と明記している。
mat2は、さまざまな形式のファイルからメタデータを取り除く道具で、元のファイルを書き換えず、filename.cleaned.pngのように「cleaned」を挟んだ新しいファイルを作る。
mat2 --show report.pdf
mat2 report.pdf
--showは、mat2が検出できる有害なメタデータを、消さずに一覧にする。ただしmat2(1)は、--showで何も表示されなくてもファイルにメタデータがないとは限らない、複雑な形式ではあらゆるメタデータを確実に検出する方法はない、とはっきり書いている。徹底して消すために、文字を選べるPDFが画像のPDFに変わるなど品質が落ちることがあり、-L(軽量モード)を使えば一部のメタデータは残る。mat2自身がまだベータだとも書いている。
点検の手順として大事なのは、処理した後のファイルを、もう一度exiftool -a -G1 -sで読み直すことだ。そして可能なら、実際に送った先から取得し直したファイルを読む。消したつもりのファイルと、相手に届いたファイルが同じとは限らない。
スマートフォンの写真#
スマートフォンでは、撮影時に位置を記録させない設定と、共有するときに位置を外す操作の二段がある。
iPhoneについて、Appleのパーソナルセーフティのガイドは、「設定」>「プライバシーとセキュリティ」>「位置情報サービス」>「カメラ」で位置情報へのアクセスを許可しない(英語版の表記はNever)ようにすると、カメラが位置を記録しなくなると説明している。共有するときは、共有シートの「オプション」(Options)で「位置情報」(Location)をオフにすると、オプションの上に「Location Not Included」に当たる表示が出る。すでに撮った写真は、写真の情報画面から「Adjust Location」に当たる項目で「No Location」を選べる(日本語の画面の文言はガイドの英語版から訳したもので、表示と異なる場合がある)。
Android(Pixel)では、Pixelカメラのヘルプによると、カメラアプリの「設定」>「その他の設定」(More settings)で「Save location」に当たる項目をオフにする。設定の名前は機種ごとに違い、Googleフォトのヘルプは、Samsungでは「Location tags」、ソニーやモトローラでは「Save location」など、メーカー別の名称の一覧を載せている。Googleフォトに入れた写真については注意が要る。同じヘルプによれば、Googleフォトで変更・削除できるのは推定された位置と手動で加えた位置だけで、カメラが自動で記録した位置はGoogleフォト上では消せない。共有アルバムやリンクごとに位置を共有するかを選べる一方、パートナー共有ではすべての写真に位置の情報が付く。Googleフォトの外に共有した写真には、この設定は影響しないとも書いている。
位置のタグを消しても、写っている建物や看板から場所を推定される余地は残る。Googleのヘルプ自身が、位置を隠しても写真の目印から推測されうると書いている。この層の話は写真からの位置特定で扱う。
復旧経路#
アカウントの点検は、カンパートメント化の設計書の棚卸し表の「復旧経路」の行を埋める作業になる。匿名の区画で使っているアカウントを一つずつ開き、再設定用のメールアドレス、電話番号、2FAのバックアップ先、ログインに使っている外部アカウント(SSO)を書き出し、そのどれかが実名の区画の値を指していないかを見る。この橋はログイン画面を何度見ても表示されず、事業者の記録の上にだけ存在する。点検の詳しい手順と、復旧できなくなる危険との釣り合いはアカウント復旧経路が「橋」になるで扱う。
公開情報#
最後の層は、すでに外に出ているものだ。自分の名前、使っているハンドル名、メールアドレス、電話番号で検索し、何が見つかるかを確かめる。手順はOSINTの記事の自己監査に沿う。サーバーを運営しているなら、SSHホスト鍵や証明書、faviconからの相関をShodan/Censysの記事の手順で確かめる。
道具を二つ挙げる。Googleの「Results about you」は、入力した名前と電話番号・メールアドレス・住所に一致する検索結果を探し、削除を申請できる機能だ。Googleのヘルプは、一部の機能が特定の市場の18歳以上の利用者に順次提供されていると書き、検索結果から消えても情報がインターネットから消えるわけではなく、元のページの運営者に連絡する必要があるとしている。日本で使えるかは、自分のアカウントで確かめてほしい。
Have I Been Pwnedは、Troy Huntが2013年から運営している、メールアドレスが既知の漏洩データに含まれているかを調べるサイトだ。同サイトのプライバシーポリシーは、検索したときに個人情報を収集・保存しないとする一方、運用に必要なWebサーバーのログを最大31日保持し、そこにはフォームに入力された情報や、場合によってはIPアドレスが含まれうると書いている。匿名の区画のメールアドレスを調べるなら、その区画の回線から調べるのが筋だ。漏洩が見つかったアドレスは、パスワードの使い回しがないかを確かめる起点になる。
チェックリストと頻度#
結果が良好でも安全を意味しない。そのうえで、点検を習慣にするための表を置く。頻度は本記事の提案で、一次資料に基づく基準ではない。脅威モデルが重い人ほど短くする。
| 層 | 確かめ方 | 良好と読める状態 | 頻度の目安 |
|---|---|---|---|
| 接続 | curl -4/-6 https://am.i.mullvad.net/json | IPと組織名がVPNの出口 | VPNの設定・アプリを変えたとき、回線を変えたとき |
| 切断時 | キルスイッチの記事の「自分で切って検証する」 | どの場面でも実IPが出ない | 月1回、VPNアプリやOSの大きな更新の後 |
| DNS | resolvectl status、tcpdumpの53・853番、確認サイト | 物理インターフェースに問い合わせが出ない。表示のDNSがISPでない | 月1回、ブラウザや拡張機能・セキュリティソフトを入れ替えたとき |
| WebRTC | BrowserLeaksかipleak.netで切断時と接続時を比較 | 接続中に自宅のアドレスが出ない | ブラウザの大きな更新の後、拡張型VPNを使い始めたとき |
| IPv6 | ip -br addr、ip -6 route show default、curl -6 | IPv6がトンネルを通るか、外に出る経路がない | 回線やルーターを変えたとき |
| 指紋 | Cover Your Tracks、AmIUnique | 使っているブラウザの戦略どおりの結果(標準化なら少数派でない、ランダム化なら毎回変わる) | ブラウザを変えたとき、拡張機能を足したとき |
| メタデータ | exiftool -a -G1 -s、mat2 --show | 位置・端末名・作成者の欄がない | ファイルを出すたび(例外なし) |
| 復旧経路 | 棚卸し表の「復旧経路」の行 | 匿名区画の再設定先が実名区画の値と重ならない | アカウントを作ったとき、半年に1回 |
| 公開情報 | 名前・ハンドルでの検索、Results about you、HIBP | 匿名区画と実名区画を結ぶ記述がない | 半年に1回 |
結果の読み方を三つ付け加える。一つ目に、確認サイトの「緑」は、その瞬間、そのブラウザ、そのサイトが試した方法の範囲での合格にすぎない。ネットワークの切り替え直後やスリープからの復帰直後の漏れは、落ち着いてから実行したテストには出ない。二つ目に、表示と実際の送信は別物で、迷ったらtcpdumpのような端末側の観測を優先する。三つ目に、結果は日付と環境と一緒に記録しておく。次の点検で何が変わったかが分かれば、どの更新が穴を開けたのかを追える。
限界と残るリスク#
この記事の点検は、自分の端末と自分のアカウントの画面から見える範囲に限られる。全項目が良好でも、次のものは確かめられないまま残る。
VPN事業者やプラットフォームのサーバーに残る記録は、点検できない。DNSリークを塞いでも、問い合わせはVPN事業者のリゾルバに移っただけだ。ログインしたアカウント、支払いの記録、アカウント同士のつながりは、事業者の側にある。文体と活動時間帯は、ブラウザの設定と無関係に残る(文章からの特定)。通信の時刻の相関は、VPNの入口と出口の両方を見られる相手に対しては、IPを隠しても残る(タイミング相関)。ブラウザや端末そのものが侵害されていれば、確認サイトの結果を含めて何も信用できない(Playpen事件とNIT)。
点検には、それ自体のリスクもある。確認サイトを開くたびに、運営者に今のIPとブラウザの特徴を渡し、Cover Your TracksやAmIUniqueでは指紋のデータベースに一件を加える。VPN事業者が運営するサイトを使えば、その事業者に「この出口からこのブラウザが点検に来た」という記録を残しうる。点検の結果を見て設定を細かくいじると、指紋が少数派に寄り、かえって目立つ。WebRTCを個別に切ったブラウザが少数派になりうることは、WebRTCの記事で触れた。キルスイッチの遮断を強くすれば、キャプティブポータルが開けないといった不便が出て、それに負けて遮断を外した瞬間が危ない。メタデータの除去も、元のファイルを上書きすれば、撮影日時のように後で自分が必要とする記録まで失う。
そして、点検表のすべてを満たしても「匿名になった」とは言えない。点検は、分かっている漏れ方を一つずつ潰したことの確認であり、相手がまだ使っていない経路や、自分が気づいていない橋までは保証しない。身近な人が相手の場合のように、端末やアカウントに直接触れられる立場の人が脅威になる状況では、この記事とは別の点検が必要になる(身近な人を相手にした脅威モデル)。
まとめ#
VPNを使い始めたばかりの人(beginner)なら、今日やることは一つでいい。VPNを切った状態で自宅の公開IPを控え、VPNにつないでからBrowserLeaksかipleak.netを開き、IP、DNS、WebRTCのどの欄にもその番号と自分のISP名が出ていないことを確かめる。出ていたら、表の「詳しい記事」の列から該当する記事を開く。
取材源や身元を守る立場(journalist)なら、通信の層より先にファイルの層を固める。外に出す写真と文書は、例外なくexiftool -a -G1 -sかmat2 --showで読み、除去した後のファイルをもう一度読む。スマートフォンのカメラの位置記録は切っておく。そのうえで、匿名区画のアカウントの復旧経路を棚卸し表に書き出す。
サーバーやVPNを自分で組んでいる人(developer)なら、確認サイトに頼らない点検を一度通しておく。tcpdumpを物理インターフェースで動かしながらトンネルを手で下ろし、ip -6 route show defaultでIPv6の経路を確かめ、自分のサーバーでwg show wg0 endpointsを見て、サーバーに記録される自分の接続元が想定どおりかを確かめる。そこで見えたものが、そのサーバーのログが押収されたときに相手が見るものだ。
出典#
参照日はいずれも2026-11-08。
- Mullvad — Connection check(Mullvad VPN AB運営。ページの説明文でVPN・DNSリーク・WebRTCリークの確認、MaxMind GeoLite2の表記。am.i.mullvad.netの
/jsonの項目は同日にコマンドで確認) - EFF — Cover Your Tracks(EFFのプロジェクト。テスト結果の表示形式「過去45日間にテストされたN件の中で一意」「少なくともXビット」「何台に1台」、あらゆる追跡を測るものではないという注記)
- EFF — Cover Your Tracks: About(2010年にPanopticlickとして開始、2020年にCover Your Tracksとして再始動。匿名で記録する項目の一覧)
- EFF — Cover Your Tracks: Privacy(IPアドレスを記録せず、定期的に捨てる鍵でハッシュ化。データセットは無期限保持、3か月のCookie、研究協力者との共有)
- EFF — Cover Your Tracks: Learn(Braveのランダム化、Tor Browserを最も現実的な防御とする記述、各項目を一般的な値に合わせるとかえって識別しやすくなりうるという警告)
- Peter Eckersley — How Unique Is Your Web Browser?(EFF、2010。少なくとも18.1ビットのエントロピー、プライバシーを意識する利用者のサンプルで83.6%が一意)
- AmIUnique(指紋の多様性の研究目的、4か月のCookie、連絡先はuniv-lille.frのアドレス。収集項目はFAQ)
- ipleak.net(ページ下部に「powered by」AirVPN。IP・WebRTC・DNS・トレント・位置情報の各確認)
- BrowserLeaks(項目別の確認ページ、個人データを収集せず指紋を保存しないという記載。運営者の名義はサイト上にない)
- Tor Project — Check(Torを使っていない接続に「Sorry. You are not using Tor.」と表示し、見えているIPを示す)
- Tor Project Support — Anti-fingerprinting(利用者を完全に同一にするのは事実上不可能で、区別可能な「バケツ」を減らすのが目標)
- Ubuntu Manpage — exiftool(1p)(Ubuntu 26.04、libimage-exiftool-perl 13.50。
-all=の例とRAWへの注意、_originalの保存、-gps:all=、APP14 Adobeグループ、PDFの変更は元に戻せるため安全な編集に使えない、-a・-G・-s) - Ubuntu Manpage — mat2(1)(Ubuntu 26.04、mat2 0.14.0。
.cleanedのファイル名、--show・-L・--inplace、検出の限界、ベータの注記) - Ubuntu Manpage — wg(8)(Ubuntu 26.04、wireguard-tools 1.0.20250521。
showのendpoints・latest-handshakes) - Ubuntu Manpage — ip-address(8)・ip(8)(Ubuntu 26.04、iproute2 6.19.0。
-brの説明) - Apple Support — Manage location metadata in Photos(カメラの位置情報サービスを「なし」に、共有シートのオプションで位置情報をオフ、「位置情報を調整」)
- Pixel Camera Help — Change your Camera app settings(「Settings」>「More settings」で「Save location」をオフ)
- Google Photos Help — Change your camera location settings(メーカー別の設定名の一覧)
- Google Photos Help — Edit your photo's location(カメラが記録した位置はGoogleフォト上で消せない、共有ごとの設定、パートナー共有、Googleフォトの外への共有には影響しない、目印から推測されうる)
- Google Search Help — Find and remove personal info in Google Search results(Results about youの対象、一部市場の18歳以上に順次提供、検索結果から消えても元のページには残る)
- Have I Been Pwned — Privacy(検索時に個人情報を収集・保存しない、Webサーバーのログは最大31日で入力内容や場合によりIPを含みうる。運営者はAbout)