- Meta（Facebook）、Yandex などの主要アプリが Android でローカルポート（127.0.0.1）を使い、Web ブラウザとネイティブアプリ間で識別子・Cookie を密かに共有していた事実が明らかになった
- Web サイトに埋め込まれた Facebook Pixel、Yandex Metrica スクリプトが Android ブラウザからネイティブアプリ（Facebook、Instagram、Yandex 系アプリ）へ ブラウジングセッションと識別子を直接渡し、ユーザー識別および匿名性の剥奪が可能になっていた
- この方式は Cookie 削除、シークレットモード、権限設定、広告 ID リセットなど既存のプライバシー保護策をすべて回避し、悪意あるアプリが対応するポートで待ち受けていれば ブラウザ閲覧履歴の収集も可能
- 2025年6月3日の公開後、Facebook 側は該当コードの大半を削除したが、この手法は数年にわたり世界中の数億台の Android 端末で利用されていた。Yandex は 2017 年から類似の方式を継続利用中
- Chrome、Firefox、Brave など主要ブラウザは緊急遮断措置を導入したが、プラットフォーム構造上の限界により根本対策は不十分であり、Android IPC とローカルネットワークのセキュリティ強化の必要性が強調されている
Disclosure: Localhostを介した秘匿的なWeb-アプリ追跡手法
- 研究者らは、Meta と Yandex が 数十億の Android ユーザーを対象に、ネイティブアプリが決められたローカルポート（例: 12580~12585、29009~30103） をバックグラウンドで開いたまま、Web 上で実行された JavaScript と通信する方式を発見した
- これにより Web ブラウザの Cookie、メタデータ、利用記録がネイティブアプリへ渡され、アプリのアカウント情報や Android Advertising ID などと組み合わされて、ユーザーの身元が Web 訪問履歴と結び付けられる
How does this work?
Androidのローカルポート悪用
- Android OS では すべてのアプリが INTERNET 権限さえあれば 127.0.0.1（ループバック）にソケットを開ける
- ブラウザ側も追加のユーザー同意なしにこのインターフェースへアクセス可能
- Web サイトに埋め込まれた JavaScript が ブラウザとネイティブアプリ間で標準 Web API を使ってデータ送受信できる
Meta/Facebook PixelのWeb-アプリ連携方式
- Meta Pixel の JavaScript は Android ブラウザで読み込まれる際、_fbp Cookie の値を WebRTC の STUN パケット（UDP 12580–12585 ポート）でネイティブアプリへ送信
- 端末内の Facebook、Instagram アプリ（バージョン別に 515.0.0.23.90 / 382.0.0.43.84 など）がそのポートで待ち受け、ブラウザから来た _fbp 値を受信して自社サーバーへ GraphQL で送信
- _fbp は上位100万サイトの約 25% に埋め込まれている主要 Cookie で、従来はサイトごとに分かれていたため横断追跡が難しかったが、この方式ではユーザーの複数の _fbp を1つのアカウントへ対応付け可能
- 2025 年 5 月以降は WebRTC TURN 方式も追加され、スクリプトは SDP Munging 手法を回避するよう変更された
- _fbp Cookie は 90 日間保持され、上位 Web サイトの 25% で使われるほど非常に一般的
- Chrome など主要ブラウザの対応後、6 月 3 日にコードを削除
Yandex MetricaのWeb-アプリ連携方式
- Yandex Metrica スクリプトは 2017 年から HTTP(S) でローカルポート（29009、29010、30102、30103 など）へリクエストを送信
- Yandex アプリ（Yandex Maps、Navigator、Browser、Search など）がポートを開いたままにし、受け取ったリクエストに対して Base64 エンコードされた Android Advertising ID（AAID） やその他のデバイス識別子、UUID などを含むデータを応答
- ブラウザスクリプトがこの情報を収集して再び Yandex サーバーへ送信し、ブラウザ-アプリ-サーバー間の識別子連携を完成させる
- yandexmetrica.com ドメインが 127.0.0.1 に名前解決され、検知回避と収集フローの秘匿化に使われていた
- localhost HTTP の利用により、もし別アプリが同じポートで待ち受けていた場合、ユーザーの Web サイト訪問履歴まで露出する危険がある
実質的なリスク: ブラウザ閲覧履歴の流出
- HTTP ベースのローカル通信を使う場合、任意の Android アプリでも該当ポートで待ち受けていればブラウザ訪問 URL などの履歴を取得可能
- 実際に Proof-of-Concept アプリを開発し、Chrome・Firefox・Edge で実験して プライベートブラウジング、シークレットモードもすべて脆弱であることを実証
- Brave、DuckDuckGo など一部ブラウザのみが独自のブロックリストとユーザー同意要求によって防御
Affected Sites
- Meta Pixel: 580 万の Web サイトで利用、実際のクローリング結果では上位 10 万サイト中 EU 1.5 万、US 1.7 万サイトでローカル ID 共有を観測
- Yandex Metrica: 300 万の Web サイトで利用、同じ方式で EU 1,260、US 1,312 サイトにおいてローカルポート通信を確認
- このうち相当数のサイトでは Cookie 同意手続きなしでも自動追跡が実行されていた
History
- Yandex: 2017 年から HTTP/HTTPS ポート利用を開始
- Meta: 2024 年 9 月 HTTP、2024 年 11 月 WebSocket、2025 年 WebRTC STUN、5 月 TURN へと段階的に移行
Abuse Vectors
- Android の localhost ソケットアクセス制限の欠如とサンドボックス方針の不備が主因
- 既存の権限設定、ブラウザのシークレットモード、広告 ID リセットなどあらゆる保護策を回避
- Web 開発目的の正当な用途との区別は難しいが、大規模追跡の実証事例として残る
- Chrome、Firefox、DuckDuckGo、Brave などのブラウザは緊急対応パッチを進めているが、根本的には プラットフォームレベルでの権限・警告、サンドボックス、IPC ポリシー強化が必要
Disclosure
- Chrome、Firefox、DuckDuckGo、Brave などのブラウザベンダーに 責任ある開示と協力を要請
- Chrome（137 バージョン）、Firefox（138 バージョン）、Brave などで 脆弱ポート遮断、SDP Munging 遮断などの短期対策を実施
- 長期的には ローカルネットワークアクセス制御、サンドボックス強化、ユーザー案内など構造的補強の必要性を強調
| ブラウザ |
バージョン |
Yandex |
Facebook |
対応/遮断状況 |
| Chrome |
136.0+ |
影響あり |
影響あり |
137 からポートおよび SDP munging を遮断、段階的に適用中 |
| Edge |
136.0+ |
影響あり |
影響あり |
不明（Chromium ベース） |
| Firefox |
138.0.2 |
影響あり |
影響なし(1) |
SDP munging を遮断、UDP は後日遮断予定 |
| DuckDuckGo |
5.233.0 |
一部影響あり(2,3) |
影響なし(2,3) |
ブロックリストベースで遮断 |
| Brave |
1.78.102 |
影響なし(3,4) |
影響なし(3,4) |
2022 年から localhost リクエストにユーザー同意を要求、ブロックリスト適用 |
- 1: SDP Munging を遮断、TURN ポートはまだ未遮断（今後適用予定）
- 2,3,4: ブロックリスト、ポート遮断、ユーザー同意など複数の防御策
ユーザー・運営者の認知状況
サイト運営者
- Meta、Yandex の公式文書ではこの方式は公開されていなかった
- 2024 年 9 月以降、Facebook 開発者フォーラムなどで "なぜ Pixel スクリプトが localhost にアクセスするのか" という問い合わせが相次いだが、公式回答はなかった
- サイト運営者も最終ユーザーも大半は認識しておらず、ユーザーが ログインしていない状態、シークレットモード、Cookie 削除などの状況でも追跡可能
一般ユーザー
- ログイン状態に関係なく追跡が動作
- シークレットモード、Cookie 削除などの保護策が無力化
- Cookie 同意手続きのないサイトでも動作する事例が多数
FAQ 要約
- Q: なぜ Meta は公開直後にこの方式を停止したのか?
A: 公式回答はないが、公開後に Android ユーザー向けのパケット送信停止が確認された
- Q: この研究はピアレビュー（査読）済みか?
A: 一部機関で検証されたが、論文審査前であり、悪用規模の大きさから迅速公開が決定された
- Q: Meta/Yandex の公式文書で公開されているのか?
A: 公式技術文書はなく、開発者フォーラムでの問い合わせだけが存在する
- Q: iOS や他プラットフォームも影響を受けるか?
A: 現時点では Android でのみ確認されているが、技術的には iOS / デスクトップ / スマートTV などにも潜在的なリスクがある
11件のコメント
バッテリーの減りが妙に激しくて、Meta系のアプリを全部削除していたんですが、こんなことがあったんですね……。adbで残りのGalaxyに内蔵されているシステムアプリも全部削除しないといけなさそうです。
私もMetaのアプリは信用できないので使わず、代わりにセキュリティフォルダ内のChromeでのみ利用しています
ハイブリッドWebアプリと呼ばれるフレームワーク類の多くは、たいてい（目的は異なるものの）localhostのWebサーバーを立ち上げます。組み込みブラウザーライブラリ（WebKit…）の設定やカスタムでも解決できないこと（Webパート）を、localhostで動かしたWebサーバー（ネイティブパート）側で解決するわけです。それをこんなふうに活用することもできたのか……惜しい
私の考えでは、ハイブリッドアプリにおけるWeb/アプリ間の一般的な通信方法は、ブリッジとも呼ばれるOSやブラウザ側が提供するAPIを介した方式です。ローカルWebサーバーは必須ではないと思います。
ここでローカルWebサーバーを使って問題になった理由は、たとえばシークレットモードのChromeからlocalhostポートにアクセスして、ユーザーの匿名性を破るような脆弱性などが成立しうるためだと思います。こうした技術がハイブリッドアプリで必須なら……ハイブリッドアプリはなくなるべきでしょう。
ドメイン名が必須となる機能や
localStorageなどを扱うために、アプリ内で Web サーバーを立てて使うのは一般的ではあります。サービスにお金を払っていないなら、自分自身が商品ということですよね。データを通じて個人を追跡しようとする試みは今後ますます増えていくでしょうし、この流れを止められるようにも見えません。より良い代替策が必要ですが、資本主義のもとでそのより良い代替策が何なのかは、正直あまり思い浮かびません。
Galaxyのセキュリティフォルダ内外でのlocalhostアクセスが分離されているのか気になります
分離されていないですね。セキュアフォルダの外で termux から Python の
http.serverを実行し、中で Chrome からアクセスすると接続できますこれってセキュリティホールじゃないんですか -_-??
SNSをやらないのが正解…のようですね
Hacker Newsのコメント
Metaが使っている全体的なトラッキングの流れを、自分の理解に基づいて整理すると、Localmessブログを参考にした内容としては次の通り
シークレットモードでも引き続き追跡可能
_fbpクッキー（閲覧情報を含む）を、WebRTC（STUN）のSDP Munging手法を使ってInstagramまたはFacebookアプリへ送信するこの処理はブラウザの開発者ツールにも表示されない部分
アプリが
_fbp情報とユーザーIDをMetaサーバーへ送るさらに注目すべき点として、
このウェブからアプリへのID共有方式は、クッキー削除、シークレットモード、Androidの権限制御といった一般的なプライバシー保護策を回避する
しかも悪意あるアプリがユーザーのウェブ活動を盗み見できる可能性まである
5月中旬以降、Meta Pixelスクリプトは
_fbpクッキーをWebRTC TURN方式でも送るようになっており、この方法はChrome開発チームがSDP Mungingをブロックした後に導入された2025年6月2日時点では、その新しいポート経由でFacebook/Instagramアプリが実際に受信する挙動は観測されていない
WebRTCの主な用途の1つが、ユーザーのローカルIPのような情報を取得して匿名性を剥がす（de-anonymize）ことだとしたら、なぜこうした機能が別途の権限要求なしで動くのか理解できない
国によっては、something-embarassing.com のようなサイトへの訪問が、気まずいで済まず、もっと深刻な結果につながり得る
完全に理解できているわけではないが、必須のGDPRクッキー同意通知を悪用して人々をひそかに追跡することまで含まれているのか気になる
インターネット広告と追跡はそのまま禁止してしまいたい
こういうもののせいで無意味なものがあまりに大量に生み出されている
要するにCEOがヨットをもう1隻買いたいがために起きている問題だと思う
Redditもかなり積極的にデバイスフィンガープリントを収集している
そのデータをAIモデル学習用として販売もしている
そのうちプレミアムアプリでしか使えない非公開データまで積極的に売る日が来ると予想している
これをどうやって禁止するのか、そして誰がその法律を破ったかをどう証明するのかという問題は残る
ブラウザからサードパーティークッキーを追放しようという流れが、現実的には最も実行可能な第一歩だった
ところがGoogleがChrome支配力を使って昨年これを頓挫させた
法的には問題なくても、消費者の怒りを買うべき非倫理的な市場操作だった
Google経営陣は当初、クッキーなしでも収益を維持する方法があると信じていたようだし、実際にはクッキーの意味をまったく理解していなかったか、あるいは最初から削除する気がなかった可能性もある
こういう行為は純粋に強欲だ
何世紀にもわたり成功してきた伝統的な経営者たちは、こうした過剰な私益追求を避けてきた
普通にまともなリーダーでも、このような低劣な振る舞いをやめて会社をもっとうまく導ける
だが強欲だけが残った世界では、ただ苦笑するしかない
もっと誠実で優秀なCEOがいてくれたらと思う
「CEOのヨット」という冗談に付け加えるなら、実際には消費者の大半は、お金を払わずに済むサービスや製品が好きだから広告モデルを選んでいる
実際、有料版と広告版があれば、広告付きのほうが10:1で人気だ
広告ブロックはむしろ状況を悪化させる — 本当の抵抗はサービスをボイコットするか、代替手段に直接支払うことのはずだ
BAT（Brave Attention Token）のように、直接サイトへ少額決済を分配する仕組みのほうがむしろ合理的だと思う
理屈としては、自分が使った分だけ支払い、広告主ではなく本当の顧客になるということだ
実際のイシューレポート: Localmessブログ
Googleは悪用事例を調査中だというが、皮肉なことにGoogle自身もWi-Fi AP名のようなさまざまなサイドチャネルを使って全員を追跡している
大手アプリ企業はOSの制限を回避するため、似たような方法でデータ収集を続けている
もう1つの理由として、ビッグテックのアプリはできるだけインストールせず、どうしても必要なときだけウェブサイトを使うようにしている
ウェブサイトは遅くて不便ではあるが、サンドボックス化されているぶんずっと安全だ
たとえばSamsung端末には複数のMetaアプリがプリインストールされており、Facebookアプリだけ消しても
com.facebook.servicesなどの隠れたサービスが残っている場合があるこれらのサービスは開発者ツール（ADB/UAD）でしか削除できない
あるいはiPhoneかPixel端末を勧める
Meta Pixelスクリプトに関する技術的情報:
Meta Pixelは2024年10月までHTTPで送信しており、Facebook/Instagramアプリはそのポートで今も待ち受けている
新設された12388ポートでも待ち受けているが、そのポートへ送信するスクリプトはまだ見つかっていない
これについて、別のアプリがこのポートに偽メッセージを送ってもよいのか気になるという科学的（？）な興味がある
1つは何も送らないこと、もう1つは大量の偽データを送ることだ
広告主の追跡クッキーをP2Pで共有する装置があってもよいと思う
このトラッキングがプロファイル間をまたいでしまうのか気になる
もしそうなら企業にとってはかなり大きなセキュリティ問題だ
Userlandアプリで8080ポートにサーバーを立てて試したところ、両方のプロファイルからアクセスできた
つまり一方のプロファイルに感染したアプリが、もう一方のプロファイルでアクセスしたサイトとデータをやり取りできるということになる
このような方法で個人が他人のコンピューターから情報収集を行った場合、CFAA（Computer Fraud and Abuse Act）で処罰され得るのか気になる
この手法では片側（閲覧中のサイト）と相手側（スマホで動作中のアプリ）の両方でコード制御が必要だ
単なる魔法のように任意のブラウザ履歴を盗み出すハッキング手法ではない
したがって明確にハッキングと見るのは難しく、Google/Metaなどが非同意トラッキングをしていたとしてもCFAAには当たらない
実際、CFAAではブラウザで単に「ページのソースを表示」しただけで起訴された人たちもいた
犯罪行為そのものより、誰を相手にしたかやネットワークとの関係のほうが重要なようだ
処罰される可能性はある
このIDシステムは悪用があまりに容易で、Googleもそれを認識し、必ず悪用防止ルールを作る必要があると分かっていたはずだと思う
ペナルティ（Play Store永久BAN、法的措置、さらには刑事告発など）にまで発展し得る問題だ
しかし現実には、Metaのように規模が大きすぎる企業に対しては実効的な制裁がほとんど不可能な状態だ
（そしてMetaでなくても、こうした怪しい動きを情報機関や法執行機関が暗黙に承認している可能性もある — 問題を止めるのは非常に難しく、口にすることすら容易ではない）
自前で追跡する方法を50種類以上持っている
他企業もユーザーデータ共有条項を大企業と再交渉しながら多額の利益を得ている
すでに取引は成立し権限も与えられていて、単に一部のユーザーがこれで騒いでいるだけだ
Firefoxでは
about:configのmedia.peerconnection.enabledオプションをfalseにしてWebRTCを無効化できるNetguardとNebuloをnon-VPNモードで組み合わせれば、Metaサーバーへの不要な接続を防げる
欧州連合（EU）はこうした問題に対して記録的水準の罰金を科すべきだと思う
問題を繰り返すたびに1〜X%ずつ累進的に上がる税のような仕組みも導入するとよいかもしれない
各企業ごとの違反事例をひと目で見られるウェブサイトも併せて必要に感じる
Metaは毎年罰金を払いながらも、700億ドル規模の純利益を出している
罰金だけでなく、場合によっては個人がもっと軽微な違反で収監された例もあるのだから、より強い措置も必要だ