ハクソク

世界を動かす技術を、日本語で。

MetaとYandexがAndroidユーザーのウェブブラウジング識別子を非匿名化している

356日前原文(arstechnica.com)

概要

MetaとYandexが提供するトラッキングコードが、Android端末上で訪問者の匿名性を破る手法を悪用。 この手法は、ブラウザからネイティブアプリへの識別子送信を可能にし、個人特定を実現。 Androidのサンドボックスやブラウザのプライバシー保護機能を回避する仕組み。 GoogleやMozillaは調査と対策を進行中。 一部ブラウザ（DuckDuckGo、Braveなど）は既に対策済み。

MetaとYandexによるAndroidユーザーのデアノニマイズ手法

  • Meta Pixel および Yandex Metrica が埋め込まれたWebサイトでのトラッキングコードの悪用

  • Android端末 にインストールされたFacebook、Instagram、Yandexアプリへの識別子送信

  • ブラウザからネイティブアプリへの ユニークID の受け渡し

  • Web識別子 と アプリユーザーID の紐付け

  • サンドボックス や ストレージパーティション 等のプライバシー保護機能を回避

    • Androidのサンドボックスによるプロセス分離の無効化
    • 各Webサイトごとに分離されたストレージ領域の突破
    • ブラウザとネイティブアプリ間の通信チャネルの悪用

  • Meta Pixel は2017年からYandex、2023年9月からMetaで本手法を開始

  • FirefoxやChromium系ブラウザ で識別子の送信が確認

  • iOS でも技術的には可能だが、Androidより制限が厳しい

技術的手法の詳細

  • ローカルポート通信 の悪用（127.0.0.1）

    • ブラウザからAndroidアプリが監視するローカルポートへリクエスト送信
    • Facebook、Instagram、Yandexアプリがリアルタイムで識別子を受信

  • WebRTC や WebSocket 等の正規プロトコルの不正利用

    • Meta Pixelは最初HTTP、後にWebSocket、WebRTC（SDP Munging）へ移行
    • SDP Mungingで _fbpクッキー をSTUNリクエストに埋め込み、アプリが受信
    • ChromeによるSDP Munging対策後、Meta PixelはTURNリクエストに切替

  • Yandex Metrica は2017年からHTTP/HTTPSでポート29009等を利用

流れの一例（Meta Pixel）

  1. ユーザーがFacebookやInstagramアプリを起動し、バックグラウンドでローカルポートを監視
  2. ユーザーがMeta Pixel埋め込み済みのWebサイトにアクセス
  3. 多くのサイトはユーザー同意なしでMeta Pixelを読み込み
  4. Meta PixelがWebRTC経由で_fbpクッキーをネイティブアプリに送信
  5. Meta Pixelは同時に_fbp値をFacebookサーバにも送信
  6. Facebook/Instagramアプリが_fbpクッキーとユーザーIDを連携し、Metaサーバへ送信

ブラウザごとの対応状況

  • DuckDuckGoブラウザ
    • トラッカー関連ドメイン・IPをブロック
    • 研究者の指摘でブラックリストを追加修正
  • Braveブラウザ
    • ローカルホストへのリクエストをユーザー同意なしにブロック
  • Vivaldiブラウザ
    • デフォルト設定では識別子送信、トラッカーブロック設定で防止可能
  • Chrome
    • SDP Munging（STUN/TURN）対策を実装、Meta Pixelは新手法で回避中
  • Firefox
    • SDP Mungingの一部が動作しないが、原理的には同様の脆弱性あり

プライバシー・セキュリティ上の問題点

  • ユーザーの匿名性喪失
    • Web上の行動履歴とアプリアカウントの結合
    • プライベートブラウジングモードでも追跡可能
  • Androidユーザーの期待・Google Play規約違反
  • サンドボックス設計原則の根本的な侵害

各社の対応と今後の課題

  • Google
    • 「本件はPlayマーケット規約とユーザープライバシー期待に反する」と声明
    • 既に一部対策を実装し、調査と関係者との協議を継続
  • Meta
    • 「Googleとのポリシー誤解について協議中。問題認識後、機能を一時停止」と声明
  • Yandex
    • コメントなし
  • Mozilla（Firefox開発元）
    • 「重大なプライバシー侵害と認識し、調査中」と声明

長期的な解決策の提案

  • ブラックリスト方式 はイタチごっこで抜本解決にならない
  • ローカルホスト通信の設計見直し が必要
    • ユーザーへの通知や許可制導入
    • ローカルチャネルの利用制限・監視強化
  • ブラウザとOSの協調によるプライバシー保護強化

まとめ

  • Meta Pixel と Yandex Metrica によるAndroid端末のトラッキング手法の悪用が確認
  • サンドボックスやストレージ分離 などの基本的なセキュリティ原則を破壊
  • Google、Mozilla、各ブラウザ開発者 が対策を進行中
  • ユーザー自身によるプライバシー設定の見直し も重要
  • 長期的にはローカル通信の設計変更と透明性向上 が求められる

Hackerたちの意見

実際の報告: https://localmess.github.io/

Googleはその悪用を調査中だと言ってるけど、ちょっと皮肉だよね。だって彼らはWi-Fi APの名前とか、手に入るあらゆるサイドチャネルを使ってみんなを追跡してるんだから。基本的に、複数のアプリを持つ大手アプリベンダーは、OSの制限を回避するために似たようなことをやってるよ。

インターネット上の広告と追跡を禁止できたらいいのに。最近は、CEOたちが余分なヨットを買うために、すごくたくさんのクソみたいなことが起こってる気がする。

└

問題は、どうやってそれを禁止するか、そして人々がそのルールを破っていることをどうやって証明するかだよね。

└

サードパーティのクッキーの廃止は、すべてのブラウザが一時的に実装する予定だった中で、実際に最も現実的な第一歩だったと思う。それが、Googleが昨年Chromeの支配力を利用して潰した理由だよね。技術的には犯罪ではないけど、すごく不快で非倫理的な市場操作だった。公衆の怒りを引き起こすこともなかったし。Googleの幹部たちが最初に支持したことも示唆的だよね。Googleのリーダーシップは、サードパーティのクッキーなしでも利益を上げる方法を見つけられると思ってたんだろうね。言い換えれば、Googleのリーダーシップは、クッキーを理解していなかったか、あるいはずっと嘘をついていて、サードパーティのクッキーの廃止を「撤回」するつもりだったのかもしれない。

└

CEOたちが余分なヨットを買えるために…消費者がサービスや商品をお金を払わずに使えるようにするためだよね。みんな広告モデルが好きなんだよ。支払うか「広告サポート」オプションを使うかの選択肢があったら、広告サポートの方が10対1で勝つんだ。つまり、多くの場合、有料オプションを持つ意味がないってこと。広告オプションの方が圧倒的に人気だからね。暗号通貨がどんなに悪いものであっても、BATは多分発明された中で一番賢いものの一つだと思う。訪れたウェブサイトに自動的にマイクロペイメントを配るブラウザトークンなんだ。細かいことは忘れて、基本的な前提はしっかりしてる：使った分だけ払う。君が顧客になって、広告主じゃなくなるんだ。それと、広告ブロックについても言いたいことがある。問題を悪化させるだけだよ。「権力に立ち向かう」抗議じゃない。抗議するなら、ボイコットしたり、競合にお金を払ったりするべきで、 compensating せずに使うのは違うよ。

└

こういうことは純粋な欲望で、普通のビジネスマンが株主のために追求してきたよりもはるかに利益の大きい機会を追い求めることとは全く異なるよ。そういう真のリーダーたちは、何世紀にもわたって成功を収めてきた伝統的な例で、欲望が支配的な力になることを許さず、過剰な自己利益に駆られた人たちとは逆の方向に進んでいる。最近は本当に恥ずかしいことだけど、みんなあまり気にしていないみたい。それが彼らを普通のビジネスマンにしている一因だね。もし平均以下なら理解できるけど、ほとんどの会社の株主は、下品な行動を避けることでパフォーマンスを上げる非欲深いCEOの方が良いと思うだろうね。もし欲望しかないなら、CEOや意思決定をする役員がその小さなツールを使って、長い間頑張ってお金を生む可能性があるかもしれない。時にはもっと欲深い力によってもそれを活用できるし。笑うしかないよね、株主は満足かもしれないけど、普通の人がそのリソースを使ったらどうなるか想像してみて。欲深い連中を恥ずかしめることができるだろうし。もし正直で平均以上のCEOが見つかったら、最高だね！

他人のコンピュータから情報を集めるためにこの技術を使った個人は、コンピュータ詐欺および悪用防止法の下で起訴される可能性があるのかな？

└

うん。

└

その法律の下で「ソースを表示」をクリックしただけで起訴された人もいるんだ。犯罪自体は関係ない。もっと重要なのは、あなたが誰で、どんなつながりがあって、誰を怒らせたかってこと。

└

これが機能するのは、両方の側でコードを制御している場合だけだよ（つまり、訪問しているウェブサイトとスマホ上のアプリ）。無作為にブラウザの履歴を抜き出すような魔法のハックじゃないから、「ハッキング」として意味のある形で解釈するのは難しいね。GoogleやMetaなどの非同意のトラッキングがどんなに悪くても、CFAAの対象にはならないんだ。

これがMetaが使っている全体のプロセスだと思う、https://localmess.github.io/からの情報だよ: 1. ユーザーがFBまたはIGアプリにログイン。アプリはバックグラウンドで動いていて、特定のポートでの着信トラフィックを監視してる。 2. ユーザーがスマホのブラウザで、たとえばsomething-embarassing.comみたいなサイトを訪れると、Meta Pixelが埋め込まれている。記事によると、Meta Pixelは580万以上のウェブサイトに埋め込まれてるんだって。インコグニートモードでも追跡される。 3. ウェブサイトは、場所によってはユーザーの同意を求めるかもしれない。記事では詳しく説明されてないけど、これは多くの人が自動的に受け入れているクッキーバナーのことかな？ 4. > Meta Pixelスクリプトは、_fbpクッキー（ブラウジング情報を含む）をWebRTC（STUN）SDPマングリングを介して、ネイティブのInstagramまたはFacebookアプリに送信する。これはブラウザの開発者ツールでは見えない。 5. ログインしたアプリを通じて、Metaは「匿名」のブラウザ活動をログインユーザーに関連付けることができる。アプリは_fbpi情報とユーザーID情報をMetaのサーバーに中継する。注目すべき点: > このウェブからアプリへのID共有方法は、クッキーをクリアすることやインコグニートモード、Androidの権限管理など、一般的なプライバシー保護を回避する。さらに悪いことに、ユーザーのウェブ活動を盗聴する悪意のあるアプリの扉を開いてしまう。 > 5月17日頃、Meta Pixelは、_fbpクッキーをSTUNの代わりにWebRTC TURNを使って送信する新しい方法をスクリプトに追加した。この新しいTURNメソッドは、Chromeの開発者が公開して無効にすると発表したSDPマングリングを回避する。2025年6月2日現在、FacebookやInstagramのアプリがこれらの新しいポートでアクティブにリスニングしているのは確認できていない。

└

あんまりついていけてないけど、あなたが言ってるのは、彼らがGDPRのクッキーノーティスを悪用して人々を密かに追跡しているってことなのかな？

└

WebRTCの主な用途はユーザーの匿名性を解除すること、つまりローカルIPアドレスを取得することなんだよね。なんでこれが許可の裏に隠れてないのか、全然理解できないわ。

└

something-embarassing.com、「あなたや家族が住んでいる国によっては、これが恥ずかしさよりもずっとひどいことになるかもしれないね。」

別のHNスレッドに書いたコメントなんだけど、これに関してはこういうことがあるよ。ウェブアプリがLANリソースにアクセスするのは、ブラウザが今でも驚くほどオープンにしている攻撃ベクターなんだ。uBlock Originには「Block Outsider Intrusion into LAN」っていうフィルターリストがあって、これがプライバシーのフィルターの下にあるんだけど、初期インストールでは有効になってないから、明示的に選択しないといけないんだよね。あと、figma.comやpcsupport.lenovo.comみたいなドメインには一部の例外がある（[1]で見えるよ）。Discordがアプリがインストールされているか確認するために6463-6472の高い番号のポートをスキャンするような半正当な使い方もあるけど、主に悪意のある行為者によるフィンガープリンティングに使われてるって記事に書いてあった。例えば、eBayはフィンガープリンティングのためにLexisNexisのスクリプトを使ってポートスキャンをしてた（2020年にはそうしてたけど、今もやってるかは不明）。詐欺防止のためらしいけどね[2]。それに、LANに侵入するウェブリクエストをブロックするためのクールなFirefox拡張「Port Authority」にも少し貢献したんだ[3][4]。これでブロックされたポートスキャンの試みが見えるんだ。uBlock Originのフィルターリストでもほぼ同じ結果が得られるけど、ブロックされた試みをもっと細かく見るのも面白いよね。とはいえ、uBlockとPort AuthorityはWebExtensionsのwebRequest [5] APIを使ってHTTP[S]/WS[S]リクエストをフィルタリングしてる。具体的に言及されているWebRTCのトリックがこのAPIにさらされているリクエストにどう関係しているのかは分からないけど、もしかしたらWebExtensionsのブロック方法を回避する可能性もあるから、そうなると良くないよね。

└

これをブロックするための仕様があるよ: https://wicg.github.io/private-network-access/ WebKitからもサポートを受けたし: https://github.com/WebKit/standards-positions/issues/163 …Mozillaからも: https://github.com/mozilla/standards-positions/issues/143 …Blinkでも試験的に導入されたけど: https://developer.chrome.com/blog/private-network-access-upd... 残念ながら、互換性の問題で今は保留中なんだ: https://developer.chrome.com/blog/pna-on-hold

└

個人的には、ブラウザはリクエストをブロックするだけじゃなくて、こういうことが試みられたら、怖い巨大な赤いバナーでウェブサイト全体をブロックすべきだと思う。プライバシー保護を回避しようとする全てのウェブサイトが、試みが成功しないかもしれないだけじゃ、あまりインセンティブがないよね。

EUはこれに対して破格の罰金を設定すべきだと思う。0%から始まって、クッキージャーに手を突っ込むたびに1-X%上がる税金を考案する時かもね。そして、企業ごとの違反を明確に見ることができるウェブサイトも追加すべきだ。

└

罰金も必要だけど、個人がそれ以下のことで刑務所に入ったこともあるからね。

すべてのアプリとウェブブラウザが共有のローカルホストインターフェースで自由に通信できるって、こんなに明らかなセキュリティホールがあるのに、iOSとAndroidがそれを許可してるのが驚きだよ。ローカルウェブサーバーを立ち上げる正当な使用例って何なんだろう？

└

なんでこれがAndroid特有なのかって疑問が湧くよね。MetaやYandexはiOSでこれをやらないの？それとも、この研究はiOSについて報告してないの？

└

アプリがローカルウェブサーバーを立ち上げる正当な使用例って何なの？iOSにはWebDAV経由で接続できる共有ドライブとして機能するアプリがあるよ。これには、WebDAV（HTTP）リクエストのためにポートをリッスンする必要があるんだ。

小さなLANツールを作ったよ。https://router.fyi で、オンラインnmapのようにLANデータを取得しようとしてるんだ。ブラウザによっては、Wi-Fiプリンターや手動で追加したスマートホームデバイスを見つけることができることもあるよ。

それってプロファイル間で機能するの？スパイウェア系の会社のアプリを使わなきゃいけなくて、通常はシェルターで隔離されたプロファイルに入れてるんだけど。隔離された「仕事用」のAndroidプロファイルで開いたローカルポートがメインプロファイルからアクセスできるか気になるな。

URLスラッグが好きだな：headline-to-come。今はもっと退屈なものにリダイレクトされてるけど。