このニュースは背筋が凍りました。

MetaがロシアのYandexと同じ手口でユーザーの行動を追跡していたことが判明、何百万ものウェブサイトに「スマホのアプリと通信するコード」を埋め込んで追跡しておりブラウザの履歴を削除しても無駄

通常、ウェブブラウザには「同一オリジンポリシー (Same-Origin Policy)」というセキュリティ機能があり、異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）間でリソースを共有することを厳しく制限しています。Cross-Origin Resource Sharing (CORS) はこの制限を緩和するためのメカニズムですが、明示的な許可が必要です。

Meta Pixel がこの規制をどのようにバイパスしたのか、最新の調査結果に基づいて説明します。

localhostソケットとWebRTCの悪用

Meta PixelがCross-Originの規制をバイパスした主な手口は、以下の組み合わせにありました。

  1. localhostポートの利用:

Metaが提供するAndroidアプリ（Facebook、Instagramなど）が、デバイス内の特定のローカルポート（例えば12580-12585）をサイレントにリッスンしていました。つまり、アプリがウェブサイトからの通信を受け入れる準備ができていたということです。

ウェブサイトに埋め込まれたMeta PixelのJavaScriptコードは、モバイルブラウザ上で実行される際に、localhost (127.0.0.1) のこれらのポートに対して通信を試みました。

localhostへの通信は、ブラウザの同一オリジンポリシーのスコープ外、またはその穴を突く形で行われました。ブラウザは、自身のデバイス内のローカルホストへの通信に対しては、比較的制限が緩い場合があります。

  1. WebRTC (Web Real-Time Communication) の利用:

Meta Pixelは、WebRTCというリアルタイム通信プロトコルを利用して、_fbp Cookie（ブラウザを識別するファーストパーティCookie）などの追跡データをlocalhostのアプリに送信していました。 WebRTCは、ブラウザ間の直接通信や、ブラウザとローカルネットワーク内のデバイスとの通信を可能にするための技術であり、その機能がこの追跡に悪用された形です。特に、WebRTCのSDP (Session Description Protocol) というセッション情報をやり取りする部分が利用されたと報告されています（SDP munging）。

  1. アプリ側でのデータリンケージ:

Androidアプリは、localhost経由で受け取った_fbp Cookieを、アプリにログインしているユーザーの永続的な識別子（Facebook IDなど）と紐付けました。

これにより、ユーザーがブラウザでCookieを削除したり、シークレットモードを使ったり、Facebook/Instagramにログインしていなくても、そのウェブ閲覧履歴がMetaのユーザーアカウントに紐付けられて追跡されるという、従来のプライバシー保護メカニズムを回避する仕組みが実現されました。

Metaとサイト運営者の責任

実際に、"Disclosure: Covert Web-to-App Tracking via Localhost on Android“という調査報告書をチェックすると、日本のドメインだけでも以下のリストに見られるようなウェブサイトがMeta Pixelを使用している惨状が明らかになります。これはほんの一部に過ぎません。

  1. https://auctions.yahoo.co.jp/
  2. https://beauty.hotpepper.jp/
  3. https://dmarket.docomo.ne.jp/
  4. https://grapee.jp/
  5. https://mechacomic.jp/
  6. https://nlab.itmedia.co.jp/
  7. https://page.auctions.yahoo.co.jp/
  8. https://trilltrill.jp/
  9. https://www.boatrace.jp/
  10. https://www.cmoa.jp/

この状況は、Metaだけでなく、サイト運営者にも重い責任 があることを示しています。

この惨状から、私は次のことを強く要求します。

  • まず、Metaは今まで不法に採取したデータをすべて廃棄すること。
  • 次に、サイト運営者はMetaから受け取った全ての違法データを廃棄すること。

これらが、ユーザーのプライバシーを守るために最低限必要な措置です。

楽天ad4U

今回のMeta Pixelの手口は、かつての「楽天ad4U」を想起させます。楽天ad4Uも一種の行動ターゲティング広告で、Adobe Flashオブジェクトの中に数千個のURLへのリンクを埋め込み、それぞれのURLを訪れた形跡があるか否かをCSSの色判定で調べる手口でした。

楽天ad4Uの手口は楽天ad4Uの隠しリンクを露出させるユーザスタイルシートなどが詳しいです。

もちろん、Meta Pixelの手口は楽天のそれとは比較にならないほど、悪い意味で洗練されたものです。ブラウザのセキュリティを破壊するために、いかに「暗い情熱」が注がれてきたかが窺えます。

ブラウザベンダーによる対策：止まらないいたちごっこ

この隠れた追跡手法が明らかになった後、主要なAndroidブラウザベンダーが問題の軽減に向けたパッチを導入または開発を進めています。しかし、その対応には大きな差が見られます。

  • Chrome: 2025年5月26日にリリースされたバージョン137で、悪用されたポートをブロックし、Meta Pixelが使用していた特定のSDP Munging形式を無効にする対策を導入しました。これらの防御策は、現在使用されているMetaおよびYandexのローカルホスト通信形式をブロックするとされています。

    • 評価: Chromeの対策は限定的と言わざるを得ません。Google自身が巨大な広告プラットフォームであり、ユーザーデータの収集がビジネスモデルの中核であるため、Google自身が「被疑者」であるという根本的な問題を抱えています。利益相反の状況では、真にユーザーのプライバシーを最優先した抜本的な対策が期待しにくいのが実情です。

  • Firefox: SDP MungingによるICEクレデンシャルのブロックを行っており、UDP通信についても今後のバージョンでブロックが予定されています。

    • 評価: 現状では限定的ですが、期待は持てます。Firefoxを開発するMozillaは非営利団体が主導しており、ユーザーのプライバシー保護への強いコミットメントがあります。過去の閲覧履歴追跡対策など、その実績は評価に値します。今後の更なるプライバシー強化策に期待が寄せられます。

  • DuckDuckGo: ブロックリストを修正し、この問題による影響を最小限に抑えました。

    • 評価: DuckDuckGoの行動は限定的過ぎます。ブロックリストによる対策は、問題が発覚してから既知のパターンを遮断する「いたちごっこ」であり、Braveのような根本的な対策には及びません。

  • Brave: 2022年以降、ローカルホスト通信にユーザーの同意を必要とし、ブロックリストも実装しているため、この問題の影響は受けていませんでした。

    • 評価: 現状見ている限りでは、Braveの対応がもっとも包括的で有用です。そもそも、問題が生じる前に対応していました。

Braveが講じた「ローカルホストアクセス許可 (Localhost Access Permission)」の仕組みは、その設計思想から非常に優れています。

Braveのローカルホストアクセス許可の優れている点

  • デフォルトでのアクセス拒否:

Braveは、デフォルトではいかなるサイトに対してもローカルホストリソースへのアクセスを許可していません。これは、ユーザーが意識的に許可しない限り、この種の通信は行われないという最も堅固なセキュリティ設定です。

多くのブラウザがローカルホスト通信に対して比較的寛容であった中で、このデフォルト拒否のスタンスは特筆すべきです。

  • ユーザーへの明確な許可プロンプト:

Braveが信頼するサイトリストに掲載されているサイトがローカルホストリソースへのアクセスを初めて試みる場合、ユーザーに明確な許可プロンプトを表示します。

これにより、ユーザーは何が起きているのかを理解し、アクセスを許可するかどうかを自分で判断できます。これは、Meta Pixelの「サイレントな通信」とは対照的です。

  • ブロックリストと許可リストの組み合わせ:

Braveは、悪用が報告されているスクリプトやサイトをブロックするフィルターリストを維持しています。

同時に、正当な理由でローカルホストアクセスが必要なサイトについては、ユーザーに許可プロンプトを表示できる「許可リスト（allow-list）」を運用しています。これにより、必要な機能とプライバシー保護を両立させています。

  • 手動での設定変更オプション:

ユーザーは、brave://settings/content/localhostAccess（デスクトップ版）または「設定 > サイトの設定 > ローカルホストアクセス」（Android版）から、個々のサイトに対するローカルホストアクセス権限を手動で管理できます。

なぜこれが包括的なのか

Meta Pixelのケースでは、WebRTCの悪用だけでなく、ローカルポートへのサイレントなアクセス自体が問題でした。Braveの対策は、特定のプロトコル（WebRTCのSDP Mungingなど）だけでなく、 ローカルホストへのあらゆるサブ要求に対してユーザーの明示的な許可を求める という、より根本的なアプローチを取っています。

これは、将来的に登場しうる新たなローカルホスト悪用手法に対しても、ある程度の防御力を持つことを意味します。他のブラウザが特定の悪用形式（SDP Mungingなど）をピンポイントでブロックしているのに対し、Braveは「ローカルホストアクセスは原則禁止、許可制」という強固なルールを敷いている点が、その包括性の根拠となります。

Googleという「被疑者」：Privacy SandboxとTopics APIの欺瞞

現在、GoogleはPrivacy Sandboxという新しい仕組みを導入し、従来のサードパーティCookieを廃止する方向に進んでいます。しかし、これが本当にユーザーのプライバシーを守るものなのか、それともGoogle自身の広告収益を維持するための戦略なのかは、まだ議論の余地があります。

Privacy Sandboxの問題点は、Googleの広告収益モデルとの整合性 が取れていないことにあります。表向きは「プライバシーを強化するための仕組み」とされていますが、実際には ユーザーの行動を広告ターゲティングに活用できるような構造 が残っているのが大きな懸念点です。

特に、FLoC（Federated Learning of Cohorts） が廃止された後、新たな代替手段として Topics API や FLEDGE が導入されました。しかし、これらの仕組みも 広告配信を最適化するためのデータ収集をGoogleが続けるためのもの という側面があり、本質的なプライバシー保護には繋がっていないという指摘がされています。

実際に、Chromeで"大阪万博限定「ICOCA」、販売拡大へ　合皮パスケースセットを“3万セット”追加"をアクセスしてみたところ、以下のようなTopicsです。

▲大阪万博に関する記事なのに、携帯電話の修理や個人ローンなどのトピックが割り当てられている例。Topics APIの課題が浮き彫りになります。

「大阪万博限定『ICOCA』」という話で、携帯電話の修理、サービス・ライブ動画ストリーミング・個人ローンなどというトピックが割り当てられるのは、整合性があるとは言えません。これはTopics APIが、ユーザーの閲覧内容を正確に反映せず、不適切なトピックを割り当てる可能性を示唆しており、プライバシー保護の観点からも問題があると言わざるを得ません。

ユーザーによる従来の対策の限界

この隠れた追跡手法が機能していた間は、ユーザーがモバイルブラウザでFacebookやInstagramにログインしていなくても、シークレットモードを使用していても、Cookieや閲覧履歴をクリアしても、 この追跡は機能していました。

つまり、従来のプライバシー保護機能（Cookieのクリア、シークレットモード、Androidのパーミッション制御など）は、この特定の手法をバイパスされていました。また、ウェブサイトがMeta Pixelスクリプトを、ユーザーがCookie同意フォームに同意する前にロードした場合でも、この追跡動作はトリガーされていました。

終わらないいたちごっこ：プラットフォーマーの責任

最も大きな問題は、楽天ad4Uの発覚後も、プラットフォーマーが悪意ある手口の開発に努めてきたことです。ユーザーのプライバシーを軽視し、巧妙な追跡手法を続ける限り、決してユーザーからの信頼は得られないでしょう。企業は利益追求のためだけでなく、社会的な責任を果たすべきです。