I decompiled the White House's new app

Original Article ↗ Hacker News Discussion ↗

A technical teardown of the official White House Android app finds it behaving much like a generic marketing app, with bundled analytics and push-notification SDKs, GPS tracking code, and JavaScript injected into in‑app webviews to hide cookie banners, consent dialogs, and some paywalls. Commenters are most alarmed by the app loading unsandboxed JavaScript from a private GitHub Pages site, which creates an obvious supply‑chain attack vector, while others argue that many commercial apps do similarly risky things and that some of the reported location‑tracking concerns may overstate what the current version actually does. The exchange broadens into questions about legal exposure (e.g., GDPR), government IT competence, and how much trust users should place in both state-backed and third‑party mobile software.

Overall reaction to the app analysis

  • Many see the app as a “standard marketing/consultancy React Native app” with common tracking SDKs and rough edges, not uniquely bad for the industry.
  • Others argue that for an official White House app, expectations should be much higher; several call it “amateur hour.”
  • Some commenters say they actually expected worse given the administration.

Location tracking and permissions (conflicting claims)

  • The article’s description of a full GPS tracking pipeline via OneSignal is seen as technically plausible but:
    • Several point out that without location permissions in the Android manifest, Android will block location access regardless of code.
    • Others initially thought the manifest lacked those permissions but later found conflicting evidence between Play Store web vs device views and different app versions.
  • One view: the pipeline is “compiled in but dead” due to missing permissions; another: earlier versions may have had them, or the article may mix versions.
  • Multiple people stress that OneSignal and similar SDKs often bundle location features by default, even if unused.

Third‑party JavaScript, hotlinking, and supply chain risk

  • Strong criticism that the app loads JS from a personal GitHub Pages site and other third‑party CDNs inside WebViews, giving whoever controls those repos arbitrary code execution.
  • Some say this would “never happen in a professional app”; others counter that hotlinking to CDNs and unpinned dependencies is common practice on the web, citing Bootstrap/HTMX/FontAwesome patterns.
  • Broad agreement that vendoring or pinning dependencies would be safer, especially for a government app.

Cookie / paywall bypass injection

  • Many users like that the injected CSS/JS removes cookie banners, GDPR dialogs, and soft paywalls, comparing it to uBlock annoyance filters or reader mode.
  • Others argue it’s legally and ethically dubious, especially when it strips consent flows on EU sites and further undermines privacy norms.

TLS, certificate pinning, and MITM

  • Some criticize lack of certificate pinning; others say it’s not standard practice and can hinder independent analysis.
  • Long subthread debates CA trust, certificate transparency logs, and corporate/MITM boxes; consensus is that HTTPS is imperfect but “good enough,” and pinning is situational, not mandatory.

Quality of the article and use of AI

  • A few suspect the writeup was partly AI‑generated (stylistic cues, large tables) and question its accuracy, especially around permissions.
  • Others push back, arguing that dismissing work “because AI” is unhelpful; they focus instead on specific technical disagreements.

UX and meta observations

  • Multiple readers complain the article’s site scrolls poorly and is GPU‑heavy, which they note is ironic given its criticism of web development.
  • Some lament the hollowing out of federal digital talent and contractors winning large sums for mediocre output.