我们截获了白宫应用程序的流量。77%的请求发送给第三方。
We intercepted the White House app's network traffic

原始链接: https://www.atomic.computer/blog/white-house-app-network-traffic-analysis/

## 白宫App数据收集:动态分析 近期对白宫iOS应用(v47.0.4)的动态分析显示,其数据收集行为与其声明的隐私政策存在显著矛盾。研究人员使用中间人代理监控了典型浏览会话期间的所有网络流量,发现只有23%的请求发送至whitehouse.gov;其余77%则定向至第三方服务。 值得注意的是,该应用在启动时会将详细的用户数据——包括IP地址、位置(语言/时区/国家)、设备信息和使用模式——发送至**OneSignal**,并随着每次会话持续更新此资料。这与应用隐私清单中声称“不收集任何数据”的说法相悖。 分析还证实了该应用在多个标签页中大量依赖**Elfsight**小部件,联系了13个Elfsight域名并设置了超过10个跟踪Cookie。此外,**Google DoubleClick**广告跟踪基础设施通过YouTube嵌入式内容加载,但未在隐私清单中披露。 该研究表明,静态代码分析与实际应用行为之间存在差异,突出了官方白宫应用中广泛的第三方跟踪行为。

最近对白宫应用程序的分析显示,**77%的网络请求被定向到第三方域名**,特别是“atomic.computer”。 这在Hacker News上引发了关于这是否不寻常的讨论。 许多评论员指出,高比例的第三方流量在许多企业对消费者(B2C)应用程序中很常见,一些用户报告说他们在分析过的其他应用程序中也发现了类似的比例。 然而,争论的焦点在于,政府应用程序是否应该比典型的商业应用程序受到*更高*的标准约束。 对话还涉及了该应用程序最初在应用商店中具有误导性的“数据收集”信息,后来已更新。 一些用户指出了讨论中潜在的转移话题策略,而另一些人则质疑,考虑到游说的普遍性,政府是否实际上像企业一样运作。 最终,共识似乎是,虽然并非特别严重,但白宫应用程序对第三方的依赖仍然令人担忧。
相关文章

原文

This is a follow-up to our static analysis of the White House iOS app. In that post, we decompiled the app and documented what the code could do. Critics fairly pointed out that compiled code doesn’t mean active code.

So we set up a MITM proxy and watched what the app actually sends.

Setup

We installed mitmproxy on a Mac, configured an iPhone to route traffic through it, and installed the mitmproxy CA certificate on the device. Then we opened the White House app (v47.0.4, build 81) and browsed every tab: Home, News, Live, Social, and Explore.

All HTTPS traffic was decrypted and logged. No modifications were made to the traffic. The app was used as any normal user would use it.

On a single browsing session across all tabs, the app made requests to 31 unique hosts (excluding iOS system traffic):

Host Requests What It Is
www.whitehouse.gov 48 WordPress API (news, home, wire, priorities, galleries, live)
www.youtube.com 25 YouTube embeds
phosphor.utils.elfsightcdn.com 19 Elfsight utility scripts
static.elfsight.com 12 Elfsight static assets
storage.elfsight.com 10 Elfsight file storage
api.onesignal.com 9 OneSignal analytics and user profiling
i.ytimg.com 9 YouTube video thumbnails
rr6—.googlevideo.com 9 Google Video CDN
scontent-lax7-1.xx.fbcdn.net 7 Facebook CDN (images)
pbs.twimg.com 7 Twitter/X images
apis.google.com 7 Google APIs
widget-data.service.elfsight.com 6 Elfsight widget data
core.service.elfsight.com 4 Elfsight boot API (the two-stage loader)
video-proxy.wu.elfsightcompute.com 4 Elfsight video proxy
img.youtube.com 4 YouTube thumbnails
yt3.ggpht.com 3 YouTube channel avatars
clients3.google.com 3 Connectivity check
scontent-lax3-1.xx.fbcdn.net 3 Facebook CDN
fonts.gstatic.com 2 Google Fonts
jnn-pa.googleapis.com 2 Google APIs
scontent-lax3-2.xx.fbcdn.net 2 Facebook CDN
www.google.com 2 Google
googleads.g.doubleclick.net 1 Google Ads / DoubleClick tracking
static.doubleclick.net 1 Google Ads
accounts.google.com 1 Google authentication
universe-static.elfsightcdn.com 1 Elfsight CDN
elfsightcdn.com 1 Elfsight CDN (platform.js)
cdnjs.cloudflare.com 1 Cloudflare CDN
ssl.gstatic.com 1 Google static
yt3.googleusercontent.com 1 YouTube
www.gstatic.com 1 Google static

Of the 206 app-initiated requests captured (excluding iOS system traffic), only 48 (23%) went to whitehouse.gov. The other 158 (77%) went to third-party services including Elfsight, OneSignal, YouTube, Google DoubleClick, Facebook, and Twitter.

What OneSignal Receives

This is no longer speculation from symbol analysis. This is the actual decrypted HTTPS request body sent to api.onesignal.com on app launch:

{
    "properties": {
        "language": "en",
        "timezone_id": "America/[REDACTED]",
        "country": "US",
        "first_active": 1774908688,
        "last_active": 1774909124,
        "ip": "[REDACTED]"
    },
    "identity": {
        "onesignal_id": "[REDACTED]"
    },
    "subscriptions": [
        {
            "id": "[REDACTED]",
            "session_time": 61,
            "session_count": 3,
            "sdk": "050500",
            "device_model": "iPhone[REDACTED]",
            "device_os": "[REDACTED]",
            "rooted": false,
            "app_version": "47.0.4",
            "net_type": 1,
            "carrier": ""
        }
    ]
}

On a single app launch, OneSignal receives:

  • Your language and timezone (narrows you to a region)
  • Your country
  • Your IP address (full IPv6)
  • When you first opened the app and when you were last active (exact timestamps)
  • Your device model and OS version (device fingerprint)
  • Whether you’re on WiFi or cellular
  • Your carrier
  • Whether your device is jailbroken
  • How many times you’ve opened the app
  • How long you spent in each session (in seconds)
  • A persistent unique identifier that tracks you across sessions

The app sent multiple PATCH requests to OneSignal on each launch, updating your profile with session counts, session time, and device metadata. In our first capture (launch only), we observed 18 PATCH requests. In our full browsing session, we observed 9 total OneSignal requests including GETs and PATCHes.

The sequence is telling: on launch, the app first performs a GET to fetch your existing profile from OneSignal’s servers, then sends PATCH requests to update it. In our captures, the GET returned a profile with an IPv6 address from a previous session. The subsequent PATCHes updated it to our current IPv4 address. This means OneSignal maintains a persistent profile that tracks your IP address changes over time. Every time you open the app from a different network, your new IP is logged against the same persistent identifier.

The User-Agent header identifies the traffic: WhiteHouse/81 CFNetwork/3860.400.51 Darwin/25.3.0

13 Elfsight Domains

Our static analysis found six Elfsight widgets and a two-stage JavaScript loader. The dynamic analysis confirms it. When you open the Social tab, the app contacts multiple Elfsight-controlled domains. Between our static analysis of platform.js and the live traffic capture, we observed the following:

  1. elfsightcdn.com (platform.js CDN)
  2. core.service.elfsight.com (boot API, returns scripts to inject)
  3. static.elfsight.com (static assets)
  4. storage.elfsight.com (file storage)
  5. phosphor.utils.elfsightcdn.com (utility scripts)
  6. universe-static.elfsightcdn.com (static CDN)
  7. widget-data.service.elfsight.com (widget data service)
  8. video-proxy.wu.elfsightcompute.com (video proxy)
  9. cors-proxy.utils.elfsightcdn.com (CORS proxy)
  10. apps.elfsight.com (apps service)
  11. dash.elfsight.com (dashboard)
  12. service-reviews-ultimate.elfsight.com (reviews service)
  13. Domain-level cookies set on elfsight.com

The /p/boot/ requests confirm the two-stage loader in action. Each widget ID is sent to core.service.elfsight.com, which responds with widget configuration and an assets array of JavaScript files to inject. Here are the actual scripts returned by the server during our capture:

// TikTok widget -> server responds with:
"assets": ["https://universe-static.elfsightcdn.com/app-releases/tiktok-feed/stable/v2.46.1/.../tiktokFeed.js"]

// Instagram widget -> server responds with:
"assets": ["https://static.elfsight.com/apps/instashow/stable/.../instashow.js"]

// Facebook widget -> server responds with:
"assets": ["https://static.elfsight.com/apps/facebook-feed/stable/.../facebookFeed.js"]

// YouTube widget -> server responds with:
"assets": ["https://static.elfsight.com/apps/yottie/stable/.../yottie.js"]

The app’s loadAssets function creates a <script> element for each URL and appends it to the page. The server decides what runs. This is the two-stage loader we documented in our static analysis now confirmed in live traffic.

The response also sets cookies including elfsight_viewed_recently, Cloudflare tracking cookies (_cfuvid, __cf_bm), and session identifiers. We counted 10+ cookies set by Elfsight infrastructure during a single session.

Google DoubleClick Ad Tracking

The YouTube embeds load Google’s ad tracking infrastructure:

  • googleads.g.doubleclick.net (Google Ads)
  • static.doubleclick.net (DoubleClick ad scripts)

DoubleClick is Google’s ad serving and tracking platform. Its presence means Google’s advertising infrastructure is running inside the official White House app, tracking user engagement with video content. This was not disclosed in the privacy manifest.

The Privacy Manifest vs. Reality

NSPrivacyCollectedDataTypes: []
NSPrivacyTracking: false

In a single browsing session, the app:

  • Sent your device model, OS, IP address, timezone, language, session count, session duration, and a persistent unique identifier to OneSignal (a third-party analytics company)
  • Contacted 13 Elfsight-controlled domains and received 10+ tracking cookies
  • Loaded Google DoubleClick ad tracking infrastructure
  • Made requests to Facebook CDN, Twitter/X CDN, YouTube, and Google APIs

The privacy label says “No Data Collected.”

Methodology

  • Proxy: mitmproxy (mitmdump) on macOS
  • Device: iPhone running iOS, connected to same WiFi network
  • Certificate: mitmproxy CA installed and trusted in iOS Certificate Trust Settings
  • Capture: Full HTTPS decryption of all app traffic
  • Duration: Single browsing session across all five tabs (Home, News, Live, Social, Explore)
  • Modifications: None. Traffic was observed, not altered.
  • Personal data: All IP addresses, device identifiers, and OneSignal IDs have been redacted from this post.

No servers were probed. No traffic was modified. We watched what the app sends on its own.

About

Atomic Computer provides cybersecurity, infrastructure, and development services. If you need a security assessment of your mobile app, get in touch.

联系我们 contact @ memedata.com