The White House App Is Spyware With a .gov Badge
A developer decompiled the official White House Android app. What they found is a disgrace to cybersecurity and the American people.
Every cybersecurity class I’ve ever sat through hammered the same thing into our heads. Ethics. Responsible disclosure. Don’t touch what you don’t have permission to touch. Don’t intercept traffic. Don’t inject code into systems you don’t own. Don’t collect data without consent. Every certification -- CompTIA, CEH, OSCP, CISSP -- opens with an ethics pledge. Every job interview asks about “ethical boundaries.” Every professor, every textbook, every conference talk drills it: the line between security research and crime is consent.
We are trained to be terrified of crossing that line. Students get expelled for scanning networks without authorization. Researchers get prosecuted for disclosing vulnerabilities. Bug bounty hunters get threatened with lawsuits for finding bugs companies didn’t want found. The entire industry is built on the principle that you do not touch, intercept, inject, collect, or surveil without explicit permission.
And then the White House ships an app that does all of it.
The Trump White House launched an official mobile app on March 28, 2026. They called it “Unparalleled access to the Trump Administration.” A security researcher who goes by Thereallo pulled the APK, threw it into JADX, and decompiled the entire thing.
What they found would get any cybersecurity student expelled, any pentester fired, and any company sued. But it’s stamped with a .gov badge, so apparently it’s fine.
This is not a political article. This is a technical audit of a government application that violates every principle the cybersecurity industry teaches. Every standard the federal government is supposed to uphold. Every ethical boundary we are told never to cross. I’m calling out everyone responsible.
Who Built This
The app was built by an entity called forty-five-press, according to the Expo configuration embedded in the APK. It’s a React Native app running on Expo SDK 54 with the Hermes JavaScript engine. The backend is WordPress with a custom REST API. The actual app logic is compiled into a 5.5 MB Hermes bytecode bundle. The native Java side is just a thin wrapper.
Version 47.0.1. Build 20. Package name: gov.whitehouse.app.
68+ SDKs compiled in. 25 native libraries in the arm64 split. For what is essentially a news reader powered by WordPress.
Finding 1: GPS Tracking Pipeline -- Your Location Every 4.5 Minutes
The app includes the OneSignal SDK for push notifications. That’s standard. What’s not standard is that the full location tracking module shipped with it -- and it’s not dead code. It’s a complete, functional pipeline.
Here’s what’s compiled into the binary:
Foreground polling: every 270,000 milliseconds (4.5 minutes)
Background polling: every 570,000 milliseconds (9.5 minutes)
Uses Google’s Fused Location API at
PRIORITY_BALANCED_POWER_ACCURACYCaptures: latitude, longitude, accuracy, timestamp, foreground/background state, fine vs. coarse location type
All data syncs to
https://api.onesignal.com/
-- a private company’s servers, not government infrastructure
A
LocationBackgroundServicecontinues capturing location even when the app isn’t active
The developers were apparently aware this was a problem. They wrote a custom Expo plugin called withNoLocation to strip location. It didn’t work. The plugin likely removed the <uses-permission> tags from the Android manifest, but the compiled OneSignal SDK code that requests those same permissions at runtime stayed in the binary. The permissions aren’t in the manifest -- they’re hardcoded as runtime request strings in the SDK itself:
android.permission.ACCESS_FINE_LOCATIONandroid.permission.ACCESS_COARSE_LOCATIONandroid.permission.ACCESS_BACKGROUND_LOCATION
Three gates must pass before tracking activates: a JavaScript-side setLocationShared(true) call, the user granting Android location permission, and a location provider being available. The researcher confirmed that both setLocationShared and isLocationShared are referenced in the Hermes bytecode bundle. Whether the JS layer currently makes that call is buried in 5.5 MB of compiled JavaScript and couldn’t be determined from native analysis alone.
But the infrastructure is there. End to end. Ready to go.
The Google Play Store listing confirms the app requests “access precise location only in the foreground” and “access approximate location only in the foreground.” So the permission dialog is there. The pipeline is there. The sync to a private company’s servers is there.
Finding 2: JavaScript Injection Into Every Website You Visit
This is the part that should make your blood boil.
Every time you open a link inside the app, it opens in a built-in WebView browser. Before you see anything, the app injects a JavaScript payload into the page. Here’s what that payload does:
It hides:
Cookie consent banners
GDPR consent dialogs
OneTrust popups
Privacy banners
Login walls
Signup walls
Upsell prompts
Paywall elements
CMP (Consent Management Platform) boxes
It targets these elements using 12+ CSS selector patterns matching class names, IDs, and aria-labels containing words like “cookie”, “consent”, “gdpr”, “onetrust”, “login-wall”, “signup-wall”, “upsell”, and “CookieBanner”.
It forces body { overflow: auto !important } to re-enable scrolling on pages that lock it behind consent dialogs.
Then it deploys a MutationObserver -- a persistent DOM watcher that continuously monitors the page and re-hides any consent elements that get dynamically added after initial load. The injector doesn’t just fire once. It fights back against sites that try to re-display their consent dialogs.
This runs on every single page load in the WebView. Every link you tap.
Let me be explicit about what this means:
A United States government application is injecting code into third-party websites to:
Strip your right to consent to tracking (GDPR, CCPA, ePrivacy Directive violations)
Bypass authentication barriers (login walls)
Circumvent paid content gates (paywall bypass -- potential CFAA and DMCA implications)
Enable silent third-party tracking (every tracker on every site fires without restriction because the consent gate was removed)
This is not a library default. This is not a leftover. Someone hand-wrote a 12-pattern CSS injector with a MutationObserver. You don’t write a MutationObserver that continuously kills consent elements by accident. That’s adversarial code. Someone tested this against sites that fight back and made sure their injector wins.
The irony: the app that profiles you through OneSignal is also stripping consent dialogs that would let you opt out of tracking on other sites.
Finding 3: Loading Code From a Random Person’s GitHub Pages
The app embeds YouTube videos using the react-native-youtube-iframe library. This library loads its player HTML from:
https://lonelycpp.github.io/react-native-youtube-iframe/iframe_v2.html
That’s a personal GitHub Pages site belonging to an individual developer. If that GitHub account gets compromised, whoever controls it can serve arbitrary HTML and JavaScript to every user of this app, executing inside the WebView context.
A government app. Loading executable code. From some guy’s personal GitHub.
This is a textbook supply chain vulnerability. The react-native-youtube-iframe library has hundreds of thousands of weekly npm downloads, and every app using it inherits this single point of failure. But a .gov application should have caught this in a security review.
The fact that they didn’t catch it tells you there wasn’t one.
Finding 4: More Third-Party Code Execution
The app also loads JavaScript from Elfsight, a commercial SaaS widget company, via https://elfsightcdn.com/platform.js. This code runs inside the WebView with no sandboxing. Whatever tracking Elfsight does, it does inside this government app. Their code can change at any time without the app being updated.
Finding 5: Your Data Goes Everywhere Except the Government
Here’s where your data actually goes when you use this “official U.S. government app”:
OneSignal (
api.onesignal.com) -- push notifications, user profiling, location data, notification interaction tracking, cross-device aliasing, behavioral segmentationMailchimp (
whitehouse.us10.list-manage.com) -- email signups. Your email goes to Mailchimp’s infrastructureUploadcare (
ucarecdn.com) -- content images hosted via hardcoded UUIDsElfsight (
elfsightcdn.com) -- social media widgets with unsandboxed JavaScriptTruth Social (
static-assets-1.truthsocial.com) -- hardcoded embed of Trump’s profileFacebook (
facebook.com/plugins/page.php) -- page plugin in an iframeLonelyCpp’s GitHub Pages (
lonelycpp.github.io) -- YouTube embed player
None of these are government-controlled infrastructure. Not one.
Federal applications are supposed to use FedRAMP-authorized services. They’re supposed to go through NIST security reviews. They’re supposed to keep citizen data on government-controlled systems. This app routes your location, your email, your browsing behavior, your notification interactions, and your device identifiers through a constellation of private companies.
Finding 6: OneSignal User Profiling -- Way Beyond Push Notifications
OneSignal isn’t just sending push notifications. The full profiling toolkit is compiled in:
addTag -- tag users for behavioral segmentation
addSms -- associate phone numbers with user profiles
addAliases -- cross-device user identification (link your phone, tablet, and any other device into one profile)
addOutcomeWithValue / addUniqueOutcome -- track user actions and conversions
Notification lifecycle tracking -- every notification received, opened, or dismissed is logged
In-app message tracking -- full lifecycle: WillDisplay, DidDisplay, WillDismiss, DidDismiss, clicked
State change tracking -- permission changes, subscription changes, user state changes
All of this data flows to OneSignal’s servers. The government gets a dashboard to segment, target, and profile users. But technically “they” don’t store the data. OneSignal does. Convenient.
Finding 7: No Certificate Pinning
The app uses standard Android TrustManager for SSL with no custom certificate pinning. If you’re on a corporate network, public WiFi, or any network with a compromised CA, all traffic between the app and its backends can be intercepted and read.
For a government app that handles citizen data. No pinning.
Finding 8: Development Artifacts in Production
The release build shipped with:
A localhost URL in the Hermes bundle:
http://localhost:8081/wp-json/whitehouse/v1/galleries?page=-- the React Native Metro dev serverA developer’s local IP:
10.4.4.109hardcoded in string resourcesThe Expo development client compiled in --
expo-dev-client,expo-devlauncher,expo-devmenuA dev menu icon in drawable resources
An exported PreviewActivity --
androidx.compose.ui.tooling.PreviewActivitywithandroid:exported="true"in the manifest. This is a development-only component exposed to the world in a production build
Finding 9: Entire External Storage Exposed
The file provider configuration exposes the entire external storage root:
<external-path name="shared" path="."/>
The WebView -- the same WebView running the consent bypass injector and loading unvetted third-party JavaScript from random GitHub accounts -- has access to your entire external storage through this file provider.
Who Failed Here
Let me name names.
Forty-five-press -- the developer entity that built this app. You shipped a government application with GPS tracking, code injection, no certificate pinning, dev artifacts in production, and third-party code loaded from a personal GitHub. This is amateur hour. A first-year computer science student would know better.
CISA (Cybersecurity and Infrastructure Security Agency) -- you are the federal agency responsible for cybersecurity. You manage the .gov domain infrastructure. The DMARC records on aliens.gov route to dmarc.cyber.dhs.gov -- you’re actively managing federal domain security. But you let this app ship? Where was the security review? Where was the code audit? Where was the FedRAMP authorization? An official government app is injecting JavaScript into third-party websites, loading code from random GitHub accounts, and routing citizen data through five private companies, and CISA had nothing to say about it?
The White House digital team -- you commissioned this app and called it “Unparalleled access to the Trump Administration.” What you delivered is unparalleled access to your users’ location, browsing behavior, notification interactions, and device identifiers, all flowing to private companies. You knew about the location issue -- you wrote a plugin called withNoLocation. It didn’t work. Did anyone check?
OneSignal -- your SDK ships with a full location tracking module that survives Expo plugins designed to strip it. When government apps include your SDK for push notifications, they get GPS tracking as a bonus. Your documentation should make this crystal clear. Developers should have to opt IN to location, not fail to opt out.
The Combined Picture
Individually, each finding is bad. Together, they paint a picture of something worse.
An app that tracks your GPS every 4.5 minutes. That strips your ability to consent to tracking on other websites. That loads and executes code from unvetted third-party sources. That routes all your data through private companies. That exposes your entire storage to its WebView. That has no certificate pinning. That shipped with dev artifacts still in the binary.
That’s not a news app. That’s spyware wearing a .gov badge.
Whether this is intentional surveillance or catastrophic negligence, the outcome for users is the same. The code is in the binary. The pipeline is built. The data flows to private servers.
The White House has not publicly responded to these technical findings.
One More Thing: Huawei Tracking Infrastructure
Independent analysis by sambent.com confirmed the app ships with 3 embedded trackers, including Huawei Mobile Services Core. Yes -- the same Chinese company the U.S. government sanctioned and banned from federal networks is shipping tracking infrastructure inside the sitting president’s official app.
You cannot make this up.
About the Researcher
Thereallo (GitHub: Thereallo1026, X/Twitter: @Thereallo1026) is a web/fullstack developer who has been building software since 2020, primarily frontend. Their blog is at thereallo.dev. Their original post drew nearly 260,000 views on X and hit the front page of Hacker News.
The developer entity behind the app, forty-five-press, operates as devfortyfive.com -- a domain registered on March 18, 2026, just 10 days before the app launched. No public information exists about who runs this company.
Credit
All technical findings in this article come from the original research by Thereallo, published March 28, 2026. Full credit to them for the decompilation work.
Original blog post: https://blog.thereallo.dev/blog/decompiling-the-white-house-app
Read the original. It includes the full Java source from JADX, the Hermes string extractions, and every code path documented. It’s excellent work.
Sources
Original Research:
Thereallo -- “I Decompiled the White House’s New App” (https://blog.thereallo.dev/blog/decompiling-the-white-house-app)
Thereallo GitHub: https://github.com/Thereallo1026
News Coverage of the Decompilation:
IBTimes UK -- “White House App Found Tracking Users’ Exact Location Every 4.5 Minutes via Third-Party Server” (https://www.ibtimes.co.uk/white-house-app-gps-tracking-controversy-1788974)
IBTimes -- “White House App Settings Grant Full Control Over Your Device: Users Warned of Extreme Risks” (https://www.ibtimes.com/white-house-app-settings-grant-full-control-over-your-device-users-warned-extreme-risks-3800465)
sambent.com -- “Fedware: 13 Government Apps That Spy Harder Than the Apps They Ban” (https://www.sambent.com/the-white-house-app-has-huawei-spyware-and-an-ice-tip-line/)
Hacker News discussion (https://news.ycombinator.com/item?id=47555556)
App Launch Coverage:
The White House -- “New White House App Delivers Unparalleled Access to the Trump Administration” (https://www.whitehouse.gov/releases/2026/03/new-white-house-app-delivers-unparalleled-access-to-the-trump-administration/)
Newsweek -- “White House Reveals New App After Cryptic Posts: Full List of Features” (https://www.newsweek.com/white-house-new-app-features-trump-administration-11749842)
The Hill -- “White House launches smartphone app” (https://thehill.com/homenews/administration/5804232-white-house-launches-trump-app/)
Engadget -- “The White House app is just as weird and unnecessary as you’d expect” (https://www.engadget.com/apps/the-white-house-app-is-just-as-weird-and-unnecessary-as-youd-expect-175354004.html)
WhistleOut -- “The White House Terrified the Internet Just To Launch a Free App” (https://www.whistleout.com/CellPhones/News/white-house-releases-new-app)
Android Authority -- “The White House has a new Android app but there’s barely any reason to install it” (https://www.androidauthority.com/white-house-android-app-3652895/)
Washington Examiner -- “White House releases new app” (https://www.washingtonexaminer.com/news/white-house/4506505/white-house-app-puts-presidency-in-pocket/)
Cryptic Videos Coverage:
Newsweek -- “What Is White House’s Cryptic Announcement? Three Theories” (https://www.newsweek.com/what-is-white-houses-cryptic-announcement-three-theories-11745691)
NewsNation -- “White House posts two cryptic videos that spark speculation” (https://www.newsnationnow.com/business/tech/white-house-posts-two-cryptic-videos-speculation/)
App Store Listings:
Apple App Store (https://apps.apple.com/us/app/the-white-house/id6759938088)
Supply Chain Component:
LonelyCpp/react-native-youtube-iframe GitHub (https://github.com/LonelyCpp/react-native-youtube-iframe)
Investigation based on decompilation research by Thereallo, published March 28, 2026. Additional findings from IBTimes, sambent.com, and independent verification. All findings derived from static analysis of the publicly available APK. No exploitation, no unauthorized access, no modification of any system. Public data only.
-- Ringmast4r, March 29, 2026