ホワイトハウス公式アプリのネットワークトラフィックを傍受して分析した結果
(atomic.computer)- ホワイトハウスのiOSアプリの実際のHTTPSトラフィックをMITMプロキシでキャプチャし、どのサーバーとどのデータをやり取りしているかを分析
- アプリはwhitehouse.gov以外にも Elfsight、OneSignal、YouTube、Google DoubleClick、Facebook、Twitter など31個のサードパーティホストと通信
- OneSignalには、言語、タイムゾーン、IP、デバイスモデル、セッション回数などのユーザープロファイリング情報が継続的に送信される
- Elfsightウィジェットローダーを通じて外部スクリプトが実行され、Google DoubleClickの広告追跡コードもアプリ内部で動作
- アプリのプライバシーマニフェストには「データ収集なし」と表示されているが、実際には多数のサードパーティ追跡とデータ送信が行われている
ネットワークトラフィック分析の概要
- ホワイトハウス公式iOSアプリのネットワークトラフィックをMITM（中間者攻撃）プロキシでキャプチャして分析
- macOS環境でmitmproxyをインストールし、iPhoneのすべてのHTTPSトラフィックをプロキシ経由で記録
- アプリのバージョンは**v47.0.4 (build 81)**で、Home、News、Live、Social、Exploreタブをすべて閲覧
- トラフィックは改変せずに復号・記録されており、一般ユーザーの利用方法そのままで実施
アプリが接続したサーバー
- 単一セッションでアプリは31個のユニークホストにリクエストを送信（iOSシステムトラフィックを除く）
- 合計206件のリクエストのうち、**48件（23%）**のみがwhitehouse.govに送信
- 残りの**158件（77%）**は、Elfsight、OneSignal、YouTube、Google DoubleClick、Facebook、Twitter などのサードパーティサービスに送信
- 主なリクエスト先
- whitehouse.gov: WordPress API（ニュース、ホーム、ギャラリーなど）
- YouTube: 動画埋め込みとサムネイル
- Elfsight: ウィジェット読み込み、静的アセット、ファイルストレージ、ブートAPIなど
- OneSignal: 分析とユーザープロファイリング
- Facebook/Twitter CDN: 画像読み込み
- Google APIs および DoubleClick: 広告と追跡
OneSignalに送信されるデータ
- アプリ起動時に
api.onesignal.comへHTTPSリクエスト本文が送信される- 含まれる情報: 言語、タイムゾーン、国、IPアドレス、初回起動および最終アクティブ時刻、デバイスモデル、OSバージョン、ネットワーク種別（WiFi/セルラー）、通信事業者、脱獄の有無、セッション回数、セッション時間、一意識別子
- アプリ起動のたびにPATCHリクエストを多数送信してプロファイルを更新
- 初回起動時に18件のPATCHリクエスト、セッション全体では9件のOneSignalリクエストを確認
- 順序: GETで既存プロファイルを照会 → PATCHでセッション情報を更新
- OneSignalはセッションごとのIP、活動時間、セッション回数、セッション継続時間を継続的に記録
- IPアドレスが変更されるとプロファイルを更新
first_activeタイムスタンプはインストール時点以後は変更されない
- 結果としてOneSignalはユーザーごとの継続的なプロファイルを維持し、アプリ利用パターンとネットワーク環境を追跡
- トラフィックのUser-Agentは
WhiteHouse/81 CFNetwork/3860.400.51 Darwin/25.3.0
Elfsight関連トラフィック
- 静的分析で確認された6個のウィジェットと2段階のJavaScriptローダーが、実際のトラフィックでも確認された
- Socialタブを開くと、アプリは13個のElfsightドメインに接続
elfsightcdn.com,core.service.elfsight.com,static.elfsight.com,storage.elfsight.com,widget-data.service.elfsight.com,video-proxy.wu.elfsightcompute.comなど
/p/boot/リクエストで各ウィジェットIDを送信すると、サーバーが**実行するスクリプト一覧（assets配列）**を返す- 例: TikTok →
tiktokFeed.js, Instagram →instashow.js, Facebook →facebookFeed.js, YouTube →yottie.js
- 例: TikTok →
- アプリの
loadAssets関数が各URLを<script>として挿入して実行- サーバーがどのコードを実行するかを決定する構造
- Elfsightサーバーはセッション中に10個以上のCookieを設定
elfsight_viewed_recently, Cloudflare追跡Cookie（_cfuvid,__cf_bm）、セッション識別子などを含む
Google DoubleClick広告追跡
- YouTube埋め込み時にGoogleの広告追跡インフラも同時に読み込まれる
googleads.g.doubleclick.net,static.doubleclick.netへのリクエストを確認
- DoubleClickはGoogleの広告配信および追跡プラットフォームであり、
ホワイトハウス公式アプリ内部で広告追跡コードが実行されている
- アプリのプライバシーマニフェストにはこの内容が明記されていない
プライバシーマニフェストと実際の動作の不一致
- アプリの申告済みプライバシー設定:
NSPrivacyCollectedDataTypes: [] NSPrivacyTracking: false - 実際のセッションで確認されたデータ送信:
- OneSignalへデバイスモデル、OS、IP、タイムゾーン、言語、セッション回数、セッション時間、一意識別子を送信
- Elfsightの13ドメインに接続し、10個以上の追跡Cookieを受信
- Google DoubleClickの広告追跡コードを実行
- Facebook、Twitter/X、YouTube、Google APIへのリクエストが発生
- 結果としてアプリは「データ収集なし」と表示されているが、実際には多数のサードパーティ追跡とデータ送信が行われている
分析方法論
- プロキシツール: mitmproxy (mitmdump)
- 環境: macOS、iPhone(iOS)、同一WiFiネットワーク
- 証明書: mitmproxy CAをiOSの信頼設定に追加
- キャプチャ範囲: アプリの5つのタブ全体を閲覧中に発生したHTTPSトラフィック
- 改変の有無: なし、トラフィックは観察のみ実施
- 個人情報の取り扱い: IP、デバイス識別子、OneSignal IDなどは投稿ですべてマスキング処理
- サーバー侵入や改変行為はなし、アプリの自発的な通信のみを記録
関連研究
- ホワイトハウスiOSアプリの静的分析レポート
- Android版のThereallo分析結果
Atomic Computerの紹介
- Atomic Computerはサイバーセキュリティ、インフラ、開発サービスを提供する企業
- モバイルアプリのセキュリティ評価および分析サービスを実施
1件のコメント
Hacker News の意見
全 3rd-party リクエストのうち 43%が Google 関連（YouTube、Fonts、Analytics を含む）で、Facebook と Twitter まで合わせると 55% 程度とのこと
政府アプリに過剰な トラッキング や分析コードが入っているのは問題だが、Google Fonts や YouTube 埋め込みはそれほど深刻ではないと思う
タイトルからは Palantir や ICE のような衝撃的なドメインを期待していたのに、Google/Facebook とは少し拍子抜けだ
タイトルは単に「77% が 3rd-party リクエスト」とするより、リクエストの 性質と深刻さ を中心に書くべきだ
ちなみに atomic.computer も Google Fonts と Analytics を使っている。3rd-party リクエスト自体を悪いものと決めつける前に、自分のサイトも点検すべきだ
結局、アプリを通じてどんなデータを追跡するかは 自分で決められる し、一般的なトラッキング事業者を経由してロンダリングするようにデータを集めることもできる
Google 関連のリクエストは透明性のために含められているようで、White House アプリを非難する意図ではない
atomic.computer は 3rd-party リクエストが本質的に悪いと言っているのではなく、データ収集と追跡の手段として分析しただけだ
ユーザーはデータが収集された後にどう使われるかを制御できず、結局 コントロールの欠如 が核心的な問題だ
mitmproxy を Mac にインストールし、iPhone のトラフィックをそこへルーティングして HTTPS を復号したとのこと
iPhone でユーザー証明書を信頼させるのが、そんなに簡単なのか気になった
Android ではネットワークトラフィックをのぞき見るのがかなり面倒だ
この種の実験は、私たちが デバイスのコントロール権 を持つべきだという点をよく示している。データがどこへ、どんな内容で送られているかを知る権利がある
以前 Zoom が中国へトラフィックを送っていた件や、Facebook がアプリ内ブラウジングデータを追跡していたことも思い出す
ただし、アプリが独自の OpenSSL を使っていたり certificate pinning を適用していたりする場合は例外だ
Facebook や Twitter のような大手アプリはたいてい pinning を使っているが、この種の単純なアプリはそうではない
ただし pinning が入ったアプリは回避が難しく、独自アプリをインストールできるプラットフォーム のほうが有利だ
銀行アプリのように pinning が強い場合は root 化された端末 が必要だ
それが ディープフェイク学習データ に使われたのかもしれない、とまで想像してしまう
関連する以前の議論スレッドがある
以前の議論 1、以前の議論 2
私は大半の広告ドメイン（例: doubleclick.net）を DNS レベルでブロック している
ニュースサイトを含め、ほとんどの Web サイトが大量の 3rd-party 接続を開いているのは驚きだ
atomic.computer も Cloudflareinsights と Google Fonts を読み込もうとするが、私のネットワークではブロックされる
こうしたリクエストが、Google にユーザーを インターネット全体で追跡 させる主な原因になっている
政府アプリには一般的な B2C アプリより はるかに高い基準 が適用されるべきだ
Google Fonts を読み込むのは構わないが、OneSignal や Facebook に テレメトリ を送るのは別問題だ
オーストラリアでは PSPF と ISM の規定上、政府データを 信頼されていない外部 に送ってはならない
こうしたアプリは IRAP 評価で即失格になる
解決策は簡単だ — フォントはセルフホスト、分析は 1st-party、外部リクエストは データ流出ベクター と見なすべきだ
多くの B2C アプリでも 3rd-party リクエスト率は 50% を超えている
White House アプリの 77% は驚くほどではないが、App Store の データ収集項目 を誤って記載していたのが問題だった
その後修正され、現在は正しく表示されている
政府アプリにも高い基準が求められるべきだが、77% という数値は業界平均と大きく変わらない可能性もある
多数のアプリが広告コードやトラッカーを含んでいるため、この程度なら 一般的な水準 かもしれない
アプリが使用している SDK の一覧は AppGoblin で確認できる
Privacy manifest では「データ収集なし」とされているが、実際には OneSignal に デバイスモデル、IP、セッション数、追跡 ID を送信している
これは明らかな 虚偽の申告（false attestation） の問題だ
次の段階はおそらく 広告の追加 だろう