Security Analysis of the Official White House iOS App

Update (March 30, 2026): Version 47.0.4 (build 81) was released. We performed a full decompilation and analysis of the new version. The consent stripping JavaScript has been removed, the always-on location permission was downgraded to when-in-use with the text “This app does not use your location,” and a YouTube player override now points to whitehouse.gov instead of a personal GitHub Pages site.

However, the privacy manifest is still empty, all six Elfsight widgets are still loading JavaScript from Elfsight-controlled infrastructure, all 10 OneSignal frameworks (including Location) are still present, there is still no certificate pinning or security hardening, and the Expo OTA infrastructure remains configured. The core security concerns are unchanged.

We followed up with a network traffic analysis that confirmed the app sends your IP address, timezone, device model, OS version, session count, session duration, and a persistent unique identifier to OneSignal on every launch, despite the permission string claiming “This app does not use your location” and the privacy manifest declaring zero data collection. Only 23% of the app’s requests go to whitehouse.gov. The other 77% go to third parties.

On March 27, 2026, the White House released its official iOS app. Published by the Executive Office of the President under the bundle ID gov.whitehouse.app, it promises citizens “direct, unfiltered access to the People’s House.”

So we took them up on it. We downloaded the app, unzipped it, and took a look at what’s inside. No hacking, no traffic interception, no DRM bypassing. Just standard macOS tools (strings, nm, plutil) pointed at a free app anyone can download from the App Store.

What we found made us do a double-take. Then a triple-take. Then we made coffee and kept going.

Yes, that’s a real string from the decompiled app. It pre-fills an SMS to short code 45470 with “Greatest President Ever!” when you tap “Text President Trump.” We tested the claim and it returned falsy.

The Basics

The app is a React Native application built with Expo and compiled with Hermes bytecode. It has five tabs (Home, News, Live, Social, and Explore) and pulls content from a WordPress REST API at whitehouse.gov. So far, so normal. A government news app built by a contractor on a standard stack. Nothing to write home about.

Then we looked at the frameworks.

Finding 1: A Russian-Origin Company Executes Live JavaScript Inside the App (Six Times)

We initially found one Elfsight widget on the Social tab. After decompiling the full Hermes bytecode, we found six:

// Decompiled from getEmbedHtml() function
{
  tiktok:    '75f7368e-61e7-4b5e-b882-e857478af97a',
  instagram: '71b6db2a-bfa4-4a74-a624-e6e63411b0d9',
  facebook:  'ab01f7f4-bcdd-4254-a6e0-8d199f5c5a8d',
  linkedin:  '1c9eb907-3575-4638-b209-3606e5845dd5',
  youtube:   '3a020a55-8a54-42f3-91b5-1c0594e0e13c',
  wire:      'f8d3fb4c-0f4e-473a-808f-c4e334bd636b'
}

Each one loads https://elfsightcdn.com/platform.js in its own WebView:

<script src="https://elfsightcdn.com/platform.js" async></script>
<div class="elfsight-app-{widget-id}" data-elfsight-app-lazy></div>

Elfsight is a widget company originally founded in Tula, Russia. It has since redomiciled to Andorra, with prior business listings in Armenia. The platform.js script is loaded at runtime from Elfsight’s CDN, meaning the code can change at any time without an app update or App Store review.

That’s six separate WebViews, each loading live, modifiable JavaScript from a company that started in Russia, each with its own cookie jar and session tracking. Each WebView has a ReactNativeWebView.postMessage() bridge available, though our deeper analysis confirmed the Elfsight WebViews have no onMessage handler on the native side, limiting the bridge to a dead end. The real risks from compromised Elfsight scripts are content injection, phishing overlays, and cookie/storage access within the WebView scope.

What platform.js actually does

We downloaded and analyzed platform.js (41,714 bytes). It’s a two-stage loader:

1. platform.js loads from Elfsight’s CDN
2. It calls core.service.elfsight.com/p/boot/?w={widget_ids}&page={document.location.href} with withCredentials: true (cookies included)
3. The server responds with widget configuration AND an assets array of additional script URLs
4. platform.js dynamically creates <script> elements for each asset URL and injects them into the page:

// From platform.js - loadAssets function
t.forEach(function(t) {
    var n = document.createElement("script");
    n.src = t;       // URL from Elfsight server response
    n.async = true;
    document.head.appendChild(n);  // injected and executed
});

Elfsight’s server decides what scripts run. There is no Subresource Integrity (SRI) hash to verify the scripts haven’t been tampered with. The app loads whatever Elfsight’s server tells it to load.

The script also broadcasts data via window.postMessage({...}, '*') with a wildcard target origin, meaning any listener (including the React Native bridge) receives the messages. It registers event listeners on scroll, mousemove, touchstart, keydown, and click at the window level. And it supports a window.eappsCustomPlatformUrl override that can redirect all Elfsight server communication to a different URL.

Elfsight’s own privacy policy states it collects IP addresses, sets tracking cookies (including session tokens and click tracking stored up to a year), and sends data to four separate Elfsight servers: core.service.elfsight.com, static.elfsight.com, service-reviews-ultimate.elfsight.com, and storage.elfsight.com.

If Elfsight’s CDN or server were compromised, or if the company were compelled to modify its response, arbitrary JavaScript would execute inside the official White House app on every user’s device, across six different attack surfaces. The two-stage loader means even if platform.js itself doesn’t change, the server response can inject different scripts at any time.

An official U.S. government application should not execute runtime JavaScript from a foreign commercial entity. Doing it six times, with a two-stage loader that lets the server inject additional scripts, doesn’t make it better.

Finding 2: GPS Tracking Infrastructure (Dormant but Remotely Activatable)

Our network traffic analysis confirmed that GPS coordinates are not currently being transmitted. However, the full tracking infrastructure remains in the app and can be activated remotely.

The app ships with 10 separate OneSignal frameworks totaling ~2.4 MB, including OneSignalLocation.framework (104 KB) with a complete location tracking pipeline:

+[OneSignalLocationManager sendLocation]
+[OneSignalLocationManager requestLocation]
+[OneSignalLocationManager resetSendTimer]
+[OneSignalLocationManager beginTask]
+[OneSignalLocationManager startLocationSharedWithFlag:]
-[OneSignalLocationManager locationManager:didUpdateLocations:]

Our decompilation confirmed that setLocationShared(true) is never called in the JavaScript layer. The traffic capture confirmed no GPS data in any request. But the capability is compiled in and can be activated remotely via OneSignal’s OSRemoteParamController (see Finding 4) without an app update.

What OneSignal does receive on every launch (confirmed via traffic capture): your IP address, timezone, country, device model, OS version, session count, session duration, and a persistent unique identifier. None of this is declared in the privacy manifest.

In the original release (v47.0.0), the app requested always-on background location permission. In v47.0.4 this was downgraded:

# v47.0.0 (original release)
NSLocationAlwaysAndWhenInUseUsageDescription: "Allow WhiteHouse to access your location"
NSLocationAlwaysUsageDescription:             "Allow WhiteHouse to access your location"
NSLocationWhenInUseUsageDescription:          "Allow WhiteHouse to access your location"

# v47.0.4 (current)
NSLocationWhenInUseUsageDescription:          "This app does not use your location."

The permission string now says “This app does not use your location” while OneSignalLocation.framework with sendLocation and requestLocation is still compiled in. There is no map, no local news, no geofencing, no weather. Nothing in the app requires location.

OneSignal is a private, VC-backed company (SignalFire, Y Combinator, HubSpot Ventures, ServiceNow) headquartered in San Mateo, CA, with data stored on Google Cloud.

Finding 3: The Privacy Manifest Is Provably False

Apple requires apps to be upfront about what data they collect, through a privacy manifest (PrivacyInfo.xcprivacy). Think of it like a nutrition label, but for your data. Here’s what the White House app puts on the label:

NSPrivacyCollectedDataTypes: []    ← empty array
NSPrivacyTracking: false

“Nothing to see here, folks. We collect absolutely nothing.”

Here is what the app actually contains, verified through binary and framework analysis:

That’s like putting “0 calories” on the label of a cheeseburger. While shipping ten different analytics frameworks. This is a violation of Apple’s App Store Review Guidelines Section 5.1.2.

Update: It gets worse. OneSignal’s own frameworks, which ship inside the app bundle, include their own privacy manifests that declare what they collect. For example, OneSignalLocation.framework declares it collects precise location, coarse location, and product interaction data:

But the app’s main privacy manifest declares an empty array:

OneSignal’s developer documentation also explicitly tells developers: “As OneSignal is a third-party service, it is your responsibility to accurately disclose what data you collect and how it’s used through OneSignal.” OneSignal did their part. The developer ignored both the framework manifests and the documentation.

Finding 4: OneSignal Can Remotely Toggle Location Tracking and Privacy Consent

We verified this against OneSignal’s open source SDK on GitHub (v5.5.0, the version used by the app at the time of writing). The server response includes a location_shared boolean that controls whether GPS tracking is active. From OneSignal.m, line 616:

if ([[OSRemoteParamController sharedController] hasLocationKey]) {
    BOOL shared = [result[IOS_LOCATION_SHARED] boolValue];
    // calls startLocationSharedWithFlag: with the server's value
}

And from OneSignalLocationManager.m, line 85, the remote parameter overrides any local setting:

+ (void)setShared:(BOOL)enable {
    // Already set by remote params
    if ([[OSRemoteParamController sharedController] hasLocationKey])
        return;  // remote params take priority
}

The comment says it: “Already set by remote params.” The server wins. We traced the full control flow and verified it across three independent sources:

1. Source code (GitHub, tagged v5.5.0): OneSignal.m reads location_shared from the server response and calls startLocationSharedWithFlag:
2. Traffic capture (network analysis): We captured the exact GET /apps/4166924e-.../ios_params.js request that triggers this code path on every app launch
3. Binary symbols: nm output from the compiled framework matches the source code method names

OneSignal’s servers can remotely enable or disable GPS tracking and change whether privacy consent is required, all without an app update, without Apple review, without the user knowing. This is a standard OneSignal SDK feature, but on a .gov app it means the location tracking light switch isn’t in the White House’s hands.

Finding 5: The App Strips Privacy Consent Banners

Update (v47.0.4): This code has been removed. The consent stripping JavaScript is no longer present in the current version of the app. The following was found in v47.0.0 and is documented here for the record.

In the original release, the app injected JavaScript into every social WebView (all six Elfsight embeds, plus the Facebook iframe) that forcibly removed cookie consent banners, GDPR notices, and login walls from embedded third-party content:

(function() {
  var css = document.createElement('style');
  css.textContent = [
    '[class*="cookie"], [id*="cookie"]',
    '[class*="consent"], [id*="consent"]',
    '[class*="gdpr"], [id*="gdpr"]',
    '[class*="onetrust"], [id*="onetrust"]',
    '[class*="login-wall"], [class*="loginWall"]',
    '[class*="signup-wall"], [class*="signupWall"]',
    '[class*="upsell"], [class*="Upsell"]',
  ].join(',') + '{ display: none !important; }';
  document.head.appendChild(css);

  var observer = new MutationObserver(function() {
    var els = document.querySelectorAll(
      '[class*="cookie" i], [class*="consent" i], [class*="gdpr" i]'
    );
    els.forEach(function(el) { el.style.display = 'none'; });
  });
  observer.observe(document.body, { childList: true, subtree: true });
})();

The code specifically targeted OneTrust and CookieConsent by name and used a MutationObserver to continuously monitor for and hide consent elements as they appeared. An official government app was programmatically circumventing legally-mandated privacy consent mechanisms on third-party websites.

Finding 6: Minimal Security Hardening

We’ve audited apps for startups with three employees that had better security than this. For an app published by the Executive Office of the President, the security posture is… well, see for yourself:

We searched the entire binary and JS bundle for any evidence of TrustKit, SSLPinning, certificate pinning, jailbreak detection strings (Cydia, MobileSubstrate, frida), or anti-tamper mechanisms. Nothing.

The app does include a secureFetch wrapper and a variable named SSL_PINNING_CONFIG, but these are misleading. We decompiled the Hermes bytecode and found the actual implementation:

// Decompiled from Hermes bytecode - Metro module 1458
Object.defineProperty(exports, "REQUIRE_HTTPS", obj2);
Object.defineProperty(exports, "isSecureApiUrl", obj3);
Object.defineProperty(exports, "secureFetch", obj5);
Object.defineProperty(exports, "SSL_PINNING_CONFIG", obj6);

// The "pinning" is a domain whitelist:
envSlot_1 = [
  "whitehouse.gov",
  "api.onesignal.com",
  "exp.host",
  "youtube.com",
  "googleapis.com"
];

// isSecureApiUrl checks hostname against the domain whitelist
// getSecurityHeaders returns { "User-Agent": "WHGov-Mobile/1.0" }
// secureFetch wraps the standard fetch() API with these checks

The implementation is a JavaScript-level domain whitelist that validates URLs against allowed hostnames. There are no SHA-256 certificate hashes, no .cer or .pem files, and no TLS-level pinning of any kind. The SocketRocket WebSocket library (SRPinningSecurityPolicy) ships with React Native and supports pinning, but the main binary never references it. It’s dead code.

Anyone on the same WiFi network (say, at a coffee shop, an airport, or a congressional hearing room) can intercept API traffic with a proxy. Anyone with a jailbroken device can hook and modify the app’s behavior at runtime. The app relies entirely on iOS’s built-in App Transport Security for HTTPS, which is bypassed trivially with a custom root certificate.

Finding 7: Dormant Over-the-Air Code Push

The Expo Updates infrastructure is fully configured but currently disabled:

EXUpdatesEnabled: false
EXUpdatesCheckOnLaunch: NEVER
EXUpdatesURL: https://u.expo.dev/1590bd5c-74a2-4dd4-8fe6-ff5552ca15b6
EXUpdatesRuntimeVersion: 47.0.0
expo-channel-name: production

Expo OTA is a standard feature used by thousands of apps, but the security implications for a government app are different. Here’s the scenario: whoever controls the Expo project account (1590bd5c-74a2-4dd4-8fe6-ff5552ca15b6) submits a native update framed as a minor bug fix that flips EXUpdatesEnabled to true. Apple approves it because nothing looks suspicious. From that point forward, arbitrary JavaScript can be pushed to every installed copy of the app without App Store review. The reloadAsync function is already in the bundle, ready to go. For a standard consumer app this is normal. For an app carrying the seal of the presidency, this is a remote code deployment pipeline that bypasses the only independent review gate (Apple) between the developer and millions of devices.

Finding 8: Full Behavioral Intelligence Pipeline

OneSignal isn’t just sending push notifications. The OneSignal SDK includes 24+ server request types that implement a complete behavioral intelligence system. These are standard SDK capabilities, but they are compiled into and available to this app:

• OSRequestOnFocus reports activeTime, netType, deviceType, and influenceParams (how long the user spent, on what network, influenced by which notifications)
• OSRequestSendOutcomesV2 measures behavioral outcomes tied to notification campaigns
• OSRequestSendSessionEndOutcomes reports session duration and influence attribution at session end
• OSSessionManager and OSChannelTracker track direct vs. indirect vs. unattributed notification influence with configurable attribution windows
• OSRequestInAppMessageViewed/Clicked/PageViewed tracks engagement with targeted in-app messages
• OSRequestCustomEvents sends custom behavioral events

This is a marketing attribution system, the kind you’d expect from a DTC brand selling mattresses, not the Executive Office of the President. It measures whether government push notifications change user behavior: which messages drive engagement, which fall flat, and how long the influence lasts.

Finding 9: YouTube Embeds Load JavaScript From a Personal GitHub Pages Site

Thanks to Thereallo’s Android analysis, we double-checked our decompiled code and confirmed the same issue exists in the iOS app. The YouTube player loads its iframe HTML from a personal GitHub Pages site:

// Line 642978 of decompiled Hermes bytecode
'https://lonelycpp.github.io/react-native-youtube-iframe/iframe_v2.html'

This is the react-native-youtube-iframe library’s default behavior. But the result is that a government app loads HTML from a personal GitHub account. If that account is compromised, arbitrary HTML and JavaScript executes inside the app’s WebView. Another supply chain dependency that should have been caught in a security review.

Update (v47.0.4): A baseUrlOverride was added pointing to https://www.whitehouse.gov/wp-content/themes/whitehouse/assets/html/youtube-player.html, meaning the YouTube player now loads from whitehouse.gov instead of GitHub Pages. However, the lonelycpp.github.io URL is still present in the bundle as a fallback.

Complete Data Flow

Every interaction with the app generates data that flows through commercial third-party infrastructure:

None of the commercial services appear to be FedRAMP authorized. Your data’s road trip looks less like a secure government pipeline and more like a startup’s Series A tech stack.

Recommendations

If the White House wanted to address these issues:

1. Remove Elfsight and self-host the social feed widget
2. Remove OneSignalLocation.framework, delete the framework and remove all location permission strings from Info.plist
3. Fix the privacy manifest to accurately declare all data collection
4. Implement certificate pinning to prevent MITM interception of API traffic
5. Remove the consent banner stripping code (fixed in v47.0.4)
6. Add security hardening: jailbreak detection, anti-tamper, runtime integrity checks
7. Audit OneSignal’s remote parameter surface, or move to self-hosted push infrastructure
8. Remove or fully disable Expo OTA configuration

None of these are difficult. A competent iOS team could address all of them in a sprint. Most of these issues would have been caught by a standard security review before publishing to the App Store. We’d be happy to help. Our rates are very reasonable and we accept purchase orders from the federal government.

Methodology

We saw the announcement on X and wondered what was inside. A few hours later with some rudimentary tools and here we are:

• Download: ipatool (authenticates with Apple ID to download the IPA from the App Store)
• Extraction: Standard unzip of the IPA
• Binary analysis: nm, otool, strings, codesign
• JS bundle analysis: Full decompilation of Hermes v96 bytecode (863,393 lines of reconstructed JavaScript) using hermes-dec
• Framework analysis: Symbol dumps of all 13 embedded frameworks
• Config analysis: plutil on all plist files, entitlements extraction

No servers were probed. No network traffic was intercepted. No DRM was bypassed. No tools were used that require jailbreaking. Everything described here is observable by anyone who downloads the app from the App Store and has a terminal. If your adversaries haven’t already done this analysis, they’re having a slow week.

Related Work

Thereallo independently performed a thorough analysis of the Android version and found the same core issues: the consent stripping injector, the OneSignal tracking pipeline, the Elfsight dependency, and the lack of certificate pinning. They also uncovered findings specific to Android, including hardcoded GPS polling intervals (4.5 minutes foreground, 9.5 minutes background), a YouTube embed loading JavaScript from a personal GitHub Pages site, and Firebase Analytics compiled into the build. Two researchers on different platforms finding the same problems on the same day is about as close to independent confirmation as security research gets. Worth a read.

Disclosure

These findings were published on the day the app was released (March 27, 2026) and reported to CISA. A report was also filed with Apple on March 30, 2026 regarding the false privacy manifest. If the developers would like to discuss these findings or need assistance addressing them, they can reach us through our contact page.

About

Atomic Computer provides cybersecurity, infrastructure, and development services. Over twenty years of experience building and securing systems, from startups to platforms like Etsy. If you need a security assessment of your mobile app, infrastructure, or development pipeline, get in touch.

And if you’re the staffer who vibe coded this app, seriously, call us. We can help.