あなたがLinkedInを開くたびに、ページはブラウザに何千もの質問を静かに投げかけています — どの拡張機能が入っているか、どのフォントが入っているか、どのGPUか、CPUのコア数は、ローカルのIPアドレスは。そしてその答えを一つのヘッダーに書き込み、その後のすべてのリクエストにくっつけていきます。あなたはそれに同意したわけでもなく、そのようすを見ることもできません。これはバグではありません。「Spectroscopy（スペクトロスコピー）」と呼ばれています。

4月初め、Fairlinked e.V.という欧州のLinkedInユーザー団体が、数え方次第で、この10年で最も詳細な、あるいは最も意外性のないブラウザフィンガープリンティングの調査結果を公開しました。LinkedIn自身のフロントエンドJavaScriptが、サイトを読み込むたびにchrome-extension://URLに対して6000から7000ものfetch()リクエストを投げ、一つずつ解決するかを試し、さらに48個のデバイス・ブラウザ特性を集め、その一式をRSAで暗号化してからその後のすべてのAPI呼び出しに添付し、LinkedInのテレメトリエンドポイントへ送り返している、というのです。

この報道はThe Next Webに取り上げられ、404 Privacyが独立に検証し、実際のペイロードを追う長文の技術的な解剖記事でコードレベルのリバースエンジニアリングもされています。Fairlinkedの姉妹組織であるTeamfluence Signal Systemsは、2026年1月にEUのDigital Markets Act（DMA — ゲートキーパー・プラットフォームがユーザーをどう扱うべきかを定める欧州規制）のもとで、ミュンヘンで既に仮処分を申し立てていました。裁判所はそれを却下しました。LinkedIn側はメディアに対し、主張は「まったくの誤り」であり、自社のスキャンは利用規約に違反する拡張機能のみを対象としている、と述べています。

本記事は、LinkedInがアイルランドやドイツで法的に許される範囲にいるかどうかについての話ではありません。この件が物語っているのは別のことです。あなたがいま読んでいるブラウザは、この手のやり口に押し返すようには設計されておらず — もっと重要なことに — 押し返しようがないのです。差し出せるアイデンティティが一つしかないからです。

linkedin.comを開いたとき、ページが実際に何をしているのか

並行して走っている仕組みが二つあります。DevToolsのパネルを開くことが一度もなくても、理解しておく価値があります。

能動的な拡張機能検知。 ページにはハードコードされた6000以上のChrome拡張機能IDのリストが同梱されています。それぞれについて、ページはその拡張機能パッケージ内の既知のファイル — たとえばchrome-extension://<id>/manifest.jsonや特定のアイコン — に対してfetch()を発行します。取得に成功すれば、その拡張機能はインストールされています。Chromeがリクエストを拒否すれば、入っていません。このトリックが効くのは、少なくとも一つの「ウェブアクセス可能リソース」を公開している拡張機能に限られますが、現実の拡張機能のほとんどはそれに該当します。記事によれば、ステルス版ではwindow.requestIdleCallback()と時間差を組み合わせて、ネットワークパネルを目立たなくしているとのことです。

受動的なDOMスキャン（「Spectroscopy」）。 これとは別に、ページはあなたのDOMを歩き回り、chrome-extension://で始まるURL参照を探します。こちらはページにコンテンツを注入するタイプの拡張機能 — ハードコードのリストが取りこぼしたもの、まだリストが学習していない新しいもの — を捕まえます。

その結果は、LinkedInが内部でAPFCと呼ぶ（「Anti-fraud Platform Features Collection」の略で、「Device Network Analysis」の意のDNAという別名もあります）フィンガープリンティング・パイプラインに流し込まれます。拡張機能リストの隣で、このパイプラインは次のようなものを収集します。

Canvasフィンガープリント

ページは特定のテキスト、曲線、色を使って隠し画像を描き、そのピクセル値を読み戻します。正確なピクセル値は、GPUドライバ、フォントラスタライザ、OSバージョンに依存します — ページ読み込みをまたいで安定し、再訪時にあなたを特定できるほどに希少な署名を生むのに十分な情報です。

WebGLレンダラー

あなたのグラフィックススタックを記述する65以上のパラメータ。ベンダー文字列、ドライババージョン、対応拡張、シェーダ精度。同じOSを走らせているノートPCとデスクトップでも、WebGL署名は異なります。

オーディオコンテキスト

無音の音声をブラウザのオシレーターとコンプレッサーのノードに通した結果から得られるフィンガープリント。オーディオスタックが違えば、浮動小数点演算の丸め方もわずかに変わります。

WebRTCによるローカルIP

WebRTCはブラウザのリアルタイム通話APIです。ネットワーク経路を発見する仕組みの副作用として、VPNの裏にいてもあなたのLAN IPアドレス — ルーターが割り当てた192.168.xや10.xの番号 — を問い合わせられてしまいます。LinkedInは問い合わせます。

ハードウェア & ロケール

CPUコア数、デバイスメモリ、画面解像度とピクセル比、タイムゾーン、言語、バッテリー残量と放電時間、インストール済みフォント、タッチ対応。Fairlinkedのレポートによれば、合計48の属性です。

そして拡張機能リスト

先に触れた、数千件規模のプローブ。多くのフィンガープリンティング論文は「インストールされている拡張機能」を「あれば便利」程度の扱いにしますが、LinkedInはこれを看板シグナルとして扱っています。

これらのシグナルは暗号化された塊にまとめられ、ページがその後に行うすべてのAPIリクエストにHTTPヘッダーとして付与されます — つまりLinkedInのバックエンドは、どのホップでも、あなたが正確にどの端末なのかを常に知っているわけです。調査によれば、LinkedInは気に入らない拡張機能を使っているユーザーに対して、アカウントの停止や警告といった措置を取っており、このデータが単に収集されているのではなく、実際に使われているという最も直接的な証拠となっています。

linkedin.comを1回読み込んだときに、ページが実際にしていること。ページは6000以上の拡張機能を試し、さらにDOMを歩いて拡張機能を探し、48個のハードウェアおよびブラウザ属性を集め、WebRTCにLAN IPを問い合わせます。合成された塊はその後のすべてのリクエストにHTTPヘッダーとして乗せられていきます。

法的な論点の下には、もう一つの本当の問いが埋まっています。LinkedInがこの規模でこれをやっているなら、他のサイトはいったいどれくらいの規模で同じことをやっているのか、という問いです。正直な答えは「大手サイトの大半は、もう少し控えめな版を走らせている」です。LinkedInが特異なのは、拡張機能リストの幅と、エンジニアリングの丁寧さにおいてだけです。消費者向けウェブの残りは、洗練度合いはまちまちながら、同じ基本プレイブックを走らせています。

問題はフィンガープリンティングではありません。アイデンティティの使い回しです。

少し引いて見てみましょう。Canvas、WebGL、WebRTC、フォント列挙 — これらは新しい技術ではありません。ここ10年のあらゆるセキュリティ研究者が、「FirefoxのresistFingerprintingを有効にしよう」あるいは「CanvasBlockerを入れよう」で締めくくられるエッセイを書いてきました。その助言は間違いではありませんが、問題の「構造を支える壁」を見落としています。

仮に完璧なフィンガープリンティング耐性を手にしたとしましょう — すべてのシグナルを正規化し、Canvasは真っ白、WebRTC接続はすべて拒否。それでもあなたのブラウザには、クッキー入れが一つ、履歴ファイルが一つ、ログイン済みセッションの集合が一つ、保存パスワード庫が一つ、インストール済み拡張機能リストが一つ、そしてネットワーク層にはIPアドレスが一つしかありません。あなたがウェブ上でやるすべてのことが、その一つのアイデンティティから出ていくのです。あなたのCanvasを読み取れないフィンガープリンターでも、LinkedInにログインした人、Facebookにログインした人、小さな独立系書店を見た人、健康ポータルを確認した人が、同じIPから、同じクッキーで、同じブラウザインスタンスから来たことは言い当てられます。そしてそのネットワーク効果はサイト横断です。LinkedInのデータは、他のどのサイトのデータと突き合わせた瞬間に、さらに有用になります。

だからこそ、一本のアンチフィンガープリンティング拡張機能を入れても、問題は実質的に解決しませんし、ふつうのブラウザの上から「VPNを使う」でも解決しません。VPNはあなたの見かけのIPを変えますが、ブラウザを複数のアイデンティティに分割はしません。クッキー入れは依然として一つ。セッションの集合も依然として一つ。LinkedInとFacebookには同じマシンが見えていて — 都合よくも — いまやそのマシンは、VPNのIP履歴と突き合わせて検証可能になった、というだけです。

タブごとのVPNという論点

ここからが、感触の変わりはじめる部分です。Bromureのすべてのタブは、それ自身が使い捨てのLinux仮想マシンなので、VPNはブラウザ全体ではなくタブに属します。コンピュータ全体にではなく、タブにです。

LinkedInのプロファイルにはスウェーデンのMullvadエンドポイントを、Facebookのプロファイルにはスイスのエンドポイントを、「雑多なリンク用」プロファイルにはCloudflare WARPを、日常の銀行用プロファイルには何もなし、と — 同じMac上で、同じBromureアプリの中で、同時に — 割り当てることができます。LinkedInにはスウェーデンの出口が見え、Facebookにはスイスの出口が見え、銀行にはあなたの実際の自宅接続が見えます。どれ一つとして、自分が同じ人のノートPCを見ていると気づくきれいな手がかりを持ちません。

左は従来のブラウザ。すべてのタブがひとつのクッキー入れ、ひとつのWebRTCスタック、ひとつのIPアドレスを共有します。フィンガープリンターは、そのすべてを横断して名寄せします。右はBromure。各タブがそれぞれのVMとVPNを持ち、WebRTCは既定でオフ、ウィンドウを閉じればマシンは消去されます。

これは理論上の分離ではありません。BromureはApple's Virtualization.frameworkを使って、タブごとに本物のLinuxカーネルを起動します。各VMは自分のカーネルネットワークスタック、自分の/etc/hosts、自分のプロセスツリー、自分のChromiumフラグ一式、そして自分の仮想ディスク上の自分のプロファイルディレクトリを持ちます。2つのフィンガープリンティングサイトにある2つのタブが、2つの異なるVPNエンドポイントに乗っているとき、それらはフィンガープリンティングが働く層から見れば、2台の別々のノートPCを使っている2人の別々の人と区別がつきません。実際にそうなのです。

タブごとのVPN設定は、プロファイルの「VPNと広告」パネルの中にあり、選択肢は3つです。Cloudflare WARP（Cloudflareの消費者向け暗号化サービス）、WireGuard（任意のプロバイダ、任意の自前サーバー — .confを貼り付け）、そしてIKEv2（企業VPN用）。VPNはVMの内側で動作するので、ゲスト側のChromiumプロセスすら、あなたの本当のIPを見ることはありません。

BromureはWebRTCを既定で無効にします

WebRTCは、BrowserGateにおけるLAN IP漏えいの直接の原因です。これはブラウザ対ブラウザの音声・映像通話のために設計されたもので、ネットワーク経路を発見する仕組みの副作用として、ローカルネットワークインターフェースを列挙するよう頼むことができてしまいます。あなたが通話しているわけではないサイトでも、バックグラウンドでその列挙を走らせ、「このユーザーはルーターから192.168.1.47を割り当てられている。つまり典型的な家庭ネットにいる。そしてそれは、このフィンガープリントの前回訪問と同じ範囲だ」といったことを学べるのです。

Bromureは、ウェブカメラとマイクの両方が有効になっていないプロファイルでは、既定でWebRTCをオフにします。具体的には、プロファイルがウェブカメラやマイクへのアクセスを必要としない場合、Bromureのランチャーは2つのChromiumフラグを追加します。

--force-webrtc-ip-handling-policy=disable_non_proxied_udp
--enforce-webrtc-ip-permission-check

そして、RTCPeerConnectionコンストラクタを何もしないスタブに置き換えるwebrtc-blockという小さなブラウザ拡張機能をロードします。この最後の部分が効きます。ポリシーフラグだけでもUDP経由のIP漏えいは止まりますが、執念深いフィンガープリンターであればRTCPeerConnectionを生成して挙動を観測できてしまうからです。スタブはコンストラクタ自体を失敗させます。結果として、WebRTCを必要としないBromureプロファイル上で、LinkedInのLAN IPトリックを試すサイトは、何も得られずに終わります。

このために何かを切り替える必要はありません。動画通話のハードウェアを有効にしていないプロファイルでは、これが既定の状態です。プロファイルの「メディア」パネルでウェブカメラやマイクの共有をオンにすれば、WebRTCを必要とするVPNや動画通話のユースケースは自動で戻ってきます。設定の建て付けは「実際に必要なときにだけオン」であり、これは本来のウェブのあるべき姿により近いものです。

隔離で解決しないこと

先に挙げておくべきことが二つあります。第一に、どのプロファイルからでもあなたが本名でLinkedInにサインインすれば、LinkedInにはあなたが誰かが分かります。隔離は、自ら進んでログインしたサービスに対してあなたを匿名化するものではありません。サイト横断のアイデンティティ突合を壊し、セッション間での受動的な再識別を止める、ということです。それは本物の勝利ですが、匿名性ではありません。

第二に、BromureはLinkedInがBromure VMの内側で拡張機能スキャンを走らせること自体は止められません。止められるのは、その結果をつまらないものにすることであり、実際そうしています。既定では、BromureプロファイルにはBromure自身の内部拡張機能以外のChrome拡張機能は入っておらず、それらはLinkedInのハードコードリストには含まれない、プロファイル単位の別の拡張機能IDに乗っています。ページは律儀に6000個のIDを探りますが、何も返ってきません。48属性のフィンガープリントは依然として収集されます — ただし、それが識別するのは、WebRTCもクッキーもIPも、あなたの他のどのVMとも重ならない、使い捨てのVM一つだけです。

これは、サイト横断相関ツールとしてのBrowserGateを無力化するには十分です。ログイン後にLinkedInからあなたを隠すには十分ではありません。そこは取り繕わないでおきます。

LinkedIn（と類似サイト）のためのBromure推奨設定

LinkedIn専用のプロファイル、あるいはFacebook専用、あるいは積極的にフィンガープリントを取ることで知られるソーシャルプラットフォーム専用のプロファイルを用意するなら、確認しておく価値のある既定値はこれらです。以下はすべてプロファイルごとの設定パネル（一覧のプロファイル横の歯車アイコン）にあります。

全般 → 閲覧データを保持：オン

既定では、Bromureはウィンドウを閉じるとすべてを破棄します。これは適当なブラウジングには適切ですが、毎日ログインするサイトには不適切です。これをオンにすると、クッキーとパスワードが専用の仮想ディスク上でセッションをまたいで残ります。毎回ログインし直す必要がなくなります。

プライバシーとセーフティ → AIフィッシング検知：オン

LinkedInを舞台にしたフィッシング — 偽のリクルーターからのメッセージが資格情報収集ページへ誘導する類 — は大きなカテゴリです。AIフィッシング検知は、現在のページのURL、可視テキスト、フォーム構造をBromureの解析サーバーに送信してスコア付けし、偽のフォームに入力する前に警告します。これを有効にするとデータがローカルVMから出ていくので、その点は知っておく価値があります。

メディア → ウェブカメラを共有：オフ

LinkedInはあなたのカメラを必要としません。ウェブカメラをオフにしておけばWebRTCも無効のままになり、これがFairlinked調査が記録したローカルIP漏えいへの直接の対策になります。

メディア → マイクを共有：オフ

同じ理由です。WebRTCの自動キルスイッチが発動するには、ウェブカメラとマイクの両方がオフである必要があります（WebRTCはこれら両方が依存するAPIです）。

ファイル転送 → ファイルダウンロード：オフ

通常のLinkedIn利用でLinkedInからファイルをダウンロードする場面はありません。ダウンロードをオフにすれば、クリックすべきでなかったものをクリックしてしまっても、侵害されたページがMacに何かを落とすことはありません。履歴書を添えて求人に応募する必要があるなら、ファイルアップロードはオンのままで構いません。

VPNと広告 → WireGuard（またはWARP）：オン

これが、実地におけるタブごとVPNの論点です。LinkedInに見せたい出口（Mullvad、ProtonVPN、自前サーバー）用のWireGuard設定を貼り付け、「起動時に接続」をオンにしておけば、LinkedInにはあなたの他のどのタブとも違うIPが見えるようになります。WireGuardのプロバイダがまだ手元にないなら、WARPの方がワンクリックで楽な選択肢です。

あまり自明でない注意点をいくつか。WebRTCは既にオフです — ウェブカメラとマイクの両方がオフであるかぎり、このプロファイルでは設定不要で、そもそもチェックボックスも用意されていません。その2設定から派生しているからです。

仕事用にLinkedIn専用のプロファイルを運用していて、VPNセッションを個々のタブの閉鎖より長く持たせたいのであれば、閲覧データを保持を、WireGuardの起動時に接続と組み合わせてください — このプロファイルを開き直すたびに、VPNが自動で立ち上がります。

さらに進めることもできます。詳細パネルには閲覧データを暗号化というオプションがあり、これはmacOS Keychainに鍵を保管しつつ、LUKSで永続ディスクを暗号化します。それでも再起動をまたいで生かしておきたいソーシャルメディア絡みのものに対して、妥当な水準の用心深さです。

解決策の形

BrowserGateは、しばらく前から真実であり、しかも悪化しつつある何かを象徴する良い記号です。ふつうのブラウザは、この種の監視に意味ある形で押し返せません。そのアーキテクチャ全体が「ブラウザインスタンスごとにアイデンティティは一つ」という前提の上に建っているからです。特定の漏えいを緩和する拡張機能を入れることはできますし、入れるべきですが、構造的な答えは、各タブがそれ自身のコンピュータ — 自分のネットワーク、自分のプライバシー面、そして自分で終わる能力を持つコンピュータ — であるブラウザです。ウィンドウを閉じれば、そのアイデンティティ — LinkedInのスキャナーが集めた何もかも、くっついた相関クッキーの何もかも — が消えます。

これが解決策の形の全体です。LinkedInがやめることに依存してもいませんし、DMAに依存してもいません。依存しているのは、あなたのブラウザが、あなたが買ったノートPCに最初から乗っていたブラウザとは別の形をしていることです。