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.
The Basics
| Bundle ID | gov.whitehouse.app |
| Version | 47.0.0 (build 68) |
| Seller | Executive Office of the President |
| Framework | React Native (Expo) with Hermes engine |
| Size | ~40 MB |
| Built with | Xcode 26.0, iOS SDK 26.0 |
| Build environment | Expo Cloud Build (/Users/expo/...) |
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
The Social tab loads an Elfsight widget inside a WebView:
<script src="https://elfsightcdn.com/platform.js" async></script>
<div class="elfsight-app-4a00611b-befa-466e-bab2-6e824a0a98a9"
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. Its 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.
We’ll say that again: a .gov app is loading live, modifiable JavaScript from a company that started in Russia.
The WebView has a ReactNativeWebView.postMessage() bridge to the native layer. 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 core.service.elfsight.com.
If Elfsight’s CDN were compromised, or if the company were compelled to modify the script, arbitrary JavaScript would execute inside the official White House app on every user’s device.
An official U.S. government application should not execute runtime JavaScript from a foreign commercial entity.
Finding 2: GPS Tracking With No Feature Justification
Most news apps need to know what you want to read. This one wants to know where you are while you read it.
The app ships with 10 separate OneSignal frameworks totaling ~2.4 MB, including OneSignalLocation.framework (104 KB). Symbol analysis of this framework reveals a complete location tracking pipeline:
+[OneSignalLocationManager sendLocation]
+[OneSignalLocationManager requestLocation]
+[OneSignalLocationManager resetSendTimer]
+[OneSignalLocationManager beginTask]
+[OneSignalLocationManager startLocationSharedWithFlag:]
-[OneSignalLocationManager locationManager:didUpdateLocations:]
The app also declares NSLocationAlwaysAndWhenInUseUsageDescription in its Info.plist, requesting permission to track location even when the app is in the background.
There is no map, no local news, no geofencing, no “events near you,” no weather. Nothing in the app that requires location. The sendLocation method is designed to transmit GPS coordinates to OneSignal’s servers on a timed interval (foregroundSendLocationWaitTime). Whether this code path is actively enabled at runtime would require network traffic analysis, but the capability is compiled into the app and the always-on location permission is requested.
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:
| Data Type | Evidence |
|---|---|
| GPS coordinates | OneSignalLocationManager.sendLocation, setLocationWithLatitude:longitude: |
| Device identifiers | OneSignal push tokens, pushSubscriptionId, externalId |
| Behavioral analytics | OSRequestSendOutcomesV2, OSRequestOnFocus (sends activeTime, netType, deviceType, influenceParams) |
| Notification engagement | OSRequestSubmitNotificationOpened, OSRequestInAppMessageViewed/Clicked |
| Session data | OSSessionManager, OSRequestSendSessionEndOutcomes |
| User identity | OSRequestCreateUser, OSRequestIdentifyUser, OSRequestAddAliases |
| PII via contact form | handleContactForm with email, phone, street address fields |
| Email via newsletter | Mailchimp subscription at whitehouse.us10.list-manage.com |
That’s like putting “0 calories” on the label of a cheeseburger. While shipping ten different analytics frameworks. With GPS tracking. This is a violation of Apple’s App Store Review Guidelines Section 5.1.2.
Finding 4: OneSignal Can Remotely Toggle Location Tracking and Privacy Consent
Symbol analysis of OneSignalCore.framework reveals an OSRemoteParamController that accepts server-side configuration:
-[OSRemoteParamController saveRemoteParams:]
-[OSRemoteParamController saveLocationShared:]
-[OSRemoteParamController savePrivacyConsentRequired:]
-[OSRemoteParamController hasLocationKey]
-[OSRemoteParamController hasPrivacyConsentKey]
These are standard OneSignal SDK features, but the implication is significant: 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. It’s a light switch for location tracking, and it’s not in the White House’s hands.
Finding 5: The App Strips Privacy Consent Banners
The app injects JavaScript into WebViews that forcibly removes 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 targets OneTrust and CookieConsent by name and uses a MutationObserver to continuously monitor for and hide consent elements as they appear.
To put it plainly: when a website asks “Do you consent to cookies?” this app answers “You don’t get to ask,” on behalf of the user, silently. An official government app is 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:
| Security Control | Status |
|---|---|
| Certificate pinning | None (the app includes a JS-level domain whitelist and a secureFetch wrapper, but no TLS-level certificate or public key pinning. No SHA-256 pin hashes exist in the bundle.) |
| Jailbreak detection | None |
| Anti-tampering | None |
| Anti-debugging | None |
| Code obfuscation | None (Hermes bytecode only) |
| App attestation | None |
| Runtime integrity checks | None |
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.endsWith(domain)
// getSecurityHeaders returns { "User-Agent": "WHGov-Mobile/1.0" }
The implementation is a JavaScript-level domain whitelist that checks if a URL’s hostname endsWith an allowed domain. 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.
Worse, the domain whitelist itself is bypassable. The endsWith check has no dot-boundary validation, which means an attacker who registers evilwhitehouse.gov or fakeyoutube.com passes the check. The correct implementation would verify hostname === domain || hostname.endsWith('.' + domain). As written, this security control can be defeated with a $12 domain registration.
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:
OSRequestOnFocusreportsactiveTime,netType,deviceType, andinfluenceParams(how long the user spent, on what network, influenced by which notifications)OSRequestSendOutcomesV2measures behavioral outcomes tied to notification campaignsOSRequestSendSessionEndOutcomesreports session duration and influence attribution at session endOSSessionManagerandOSChannelTrackertrack direct vs. indirect vs. unattributed notification influence with configurable attribution windowsOSRequestInAppMessageViewed/Clicked/PageViewedtracks engagement with targeted in-app messagesOSRequestCustomEventssends 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.
Complete Data Flow
Every interaction with the app generates data that flows through commercial third-party infrastructure:
| Destination | Data | Company |
|---|---|---|
| OneSignal (San Mateo, CA / Google Cloud) | GPS (capability compiled in), device fingerprint, sessions, behavioral outcomes, notification engagement, user identity | OneSignal, Inc. (VC-backed) |
| Elfsight (Andorra, originally Russia) | IP address, session tokens, click tracking, widget views | Elfsight, SL |
| Mailchimp (Atlanta, GA) | Email address, postal code | Intuit |
| YouTube / Google | Video playback data | Alphabet |
| Facebook / Meta | Page plugin iframe data | Meta |
| Uploadcare (Vancouver, BC / AWS) | Image request logs | Tiugo Technologies |
| whitehouse.gov | Contact form PII, content API requests | U.S. Government |
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:
- Remove Elfsight and self-host the social feed widget
- Remove OneSignalLocation.framework, delete the framework and remove all location permission strings from
Info.plist - Fix the privacy manifest to accurately declare all data collection
- Implement certificate pinning to prevent MITM interception of API traffic
- Remove the consent banner stripping code
- Add security hardening: jailbreak detection, anti-tamper, runtime integrity checks
- Audit OneSignal’s remote parameter surface, or move to self-hosted push infrastructure
- 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
unzipof the IPA - Binary analysis:
nm,otool,strings,codesign - JS bundle analysis: String extraction from Hermes v96 bytecode
- Framework analysis: Symbol dumps of all 13 embedded frameworks
- Config analysis:
plutilon 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.
Disclosure
These findings were published on the day the app was released (March 27, 2026). We have not received a response from the White House or CISA at the time of publication. 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.