L’app della Casa Bianca dovrebbe essere un esempio di solidità tecnica e trasparenza. Eppure, un’analisi indipendente condotta sul pacchetto Android della White House App sta sollevando parecchie sopracciglia nella comunità della sicurezza informatica. Non si parla di una falla critica o di un attacco riuscito, ma di una radiografia dettagliata dell’architettura software di un’applicazione governativa distribuita pubblicamente sugli store. E quello che ne emerge, francamente, lascia più di qualche perplessità.
Il ricercatore ha estratto il contenuto dell’app utilizzando strumenti standard come ADB (Android Debug Bridge) e il decompiler JADX, due tool noti a chiunque lavori nell’ambito della sicurezza mobile. Il pacchetto APK, che altro non è se non un archivio ZIP strutturato, una volta aperto ha rivelato codice JavaScript, configurazioni Expo, endpoint API e riferimenti a servizi backend. Nulla di particolarmente sofisticato come procedura: il punto è che molte informazioni sensibili erano recuperabili senza dover ricorrere a tecniche avanzate. La White House App utilizza il motore Hermes di Meta per il bytecode JavaScript, ma “compilato” non vuol dire affatto “invisibile”. Token, URL amministrativi, configurazioni Firebase, riferimenti AWS e chiavi analytics sono emersi già da una prima scansione. Endpoint API hardcoded, configurazioni relative ai permessi Android e riferimenti a un backend WordPress REST API completano un quadro che, per un’app istituzionale, appare quantomeno discutibile.
WebView manipolata e geolocalizzazione pronta all’uso
Tra gli elementi più controversi c’è il comportamento della WebView, il componente che consente all’app di aprire pagine web al suo interno. Stando all’analisi, ogni volta che una pagina viene caricata, l’app inietta codice JavaScript che crea dinamicamente regole CSS pensate per nascondere cookie banner, finestre di consenso GDPR, login wall, signup wall e persino elementi associati a paywall. Lo script forza questi elementi a scomparire e riattiva lo scroll della pagina sottostante. Non finisce qui: viene anche creato un MutationObserver, un meccanismo che intercetta nuovi elementi aggiunti dinamicamente alla pagina e li nasconde appena compaiono. L’app della Casa Bianca, in pratica, non si limita ad aprire un sito esterno: modifica il modo in cui quel sito viene mostrato all’utente.
Altro capitolo delicato: la geolocalizzazione. Nel codice emergono costanti relative ai permessi Android per la localizzazione fine, approssimata e in background. Compaiono anche intervalli di aggiornamento piuttosto specifici: circa 4,5 minuti in foreground e circa 9,5 minuti in background. I dati raccoglibili includono latitudine, longitudine, accuratezza e timestamp. L’infrastruttura tecnica per tracciare la posizione degli utenti e inviarla a OneSignal, un fornitore terzo, risulta compilata nel pacchetto. Il plugin che avrebbe dovuto eliminare la geolocalizzazione, a quanto pare, non ha rimosso il codice nativo dell’SDK. Va detto chiaramente: questo non significa che l’app spii automaticamente tutti. Significa però che l’intera catena tecnica per farlo è già presente e potenzialmente attivabile.
Dipendenze esterne, artefatti di sviluppo e il nodo della supply chain
Un dettaglio sorprendente riguarda l’integrazione dei video YouTube: l’app carica il player HTML da un indirizzo ospitato su GitHub Pages, legato all’account personale di un manutentore. Se quell’account venisse compromesso, chi ne prendesse il controllo potrebbe teoricamente servire codice modificato a tutte le istanze dell’app. Per un’applicazione governativa, una dipendenza del genere appare difficile da giustificare. Si aggiungono widget caricati da Elfsight, una piattaforma commerciale per feed social, oltre a servizi come Mailchimp per le email, Uploadcare per le immagini e integrazioni con Facebook e Truth Social. Un ecosistema molto ampio di infrastrutture non governative da cui la White House App dipende per funzionare.
L’app non implementa certificate pinning personalizzato, affidandosi al TrustManager standard di Android. Le connessioni HTTPS restano cifrate, ma per un’app che integra notifiche, WebView, servizi esterni e identificativi utente, la scelta meriterebbe una valutazione tecnica più severa.
La parte forse più imbarazzante riguarda gli artefatti di sviluppo finiti nella build di produzione: un URL localhost verso una rotta WordPress, un IP locale nelle risorse, componenti Expo dev client e dev menu compilati nella release. Il ricercatore elenca oltre 68 librerie integrate. Ogni libreria porta con sé aggiornamenti, vulnerabilità potenziali, licenze e superfici di attacco aggiuntive.
In Europa una situazione simile verrebbe letta attraverso il principio di minimizzazione previsto dal GDPR: una Pubblica Amministrazione deve trattare solo i dati strettamente necessari alla finalità dichiarata, in modo proporzionato, documentabile e verificabile. Per le app governative italiane ed europee esistono già riferimenti normativi come le linee guida AgID, il Codice dell’amministrazione digitale e le indicazioni del Garante Privacy, anche se la pratica resta spesso disomogenea.
