We Intercepted the White House App’s Network Traffic. Here’s What It Sends.

💥 Explore this trending post from Hacker News 📖

📂 **Category**:

💡 **What You’ll Learn**:

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:

💬

On a single app launch, OneSignal receives:

  • Your language and timezone (narrows you to a region)
  • Your country
  • Your IP address (full IPv6 or IPv4, we observed both)
  • 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