Bannières cookies supprimées, paywalls contournés, traceur GPS intégré, code chargé depuis le compte GitHub d’un parfait inconnu. La nouvelle application officielle de la Maison-Blanche, disponible sur l’App Store et Google Play depuis cette semaine, promet « un accès sans précédent à l’administration Trump ». Un développeur a décidé de vérifier par lui-même ce que l’app faisait vraiment, en décompilant son code source.
Le résultat, publié sur le blog technique thereallo.dev et repris massivement sur Hacker News, dresse un portrait préoccupant : derrière la vitrine de communication, l’application embarque des mécanismes de collecte de données, de contournement de réglementations européennes et de dépendances tierces qui soulèvent des questions fondamentales sur la sécurité et la vie privée des utilisateurs.
Du JavaScript injecté pour effacer les bannières cookies de tous les sites
Le constat le plus spectaculaire concerne le navigateur intégré à l’application. Chaque fois qu’un utilisateur ouvre un lien externe dans l’app, un script JavaScript est automatiquement injecté dans la page web visitée. Ce script cible et supprime les bannières de consentement aux cookies, les boîtes de dialogue RGPD, les murs d’inscription, les prompts de vente additionnelle, et même les paywalls des sites de presse.
Le développeur qui a mené l’analyse a extrait ce snippet directement du bytecode Hermes compilé dans l’APK Android. Le script utilise un MutationObserver, un mécanisme qui surveille en permanence le DOM de la page et détruit automatiquement tout élément de consentement ajouté dynamiquement. En clair, même si un site recharge sa bannière cookie après le chargement initial, l’app la supprime à nouveau.
Pour les sites européens, c’est un point critique. Le Règlement général sur la protection des données (RGPD) impose aux sites web de recueillir le consentement explicite des utilisateurs avant de déposer des cookies. Une application gouvernementale américaine qui supprime ces demandes de consentement viole de facto le cadre juridique européen pour tout utilisateur qui ouvrirait un site soumis au RGPD depuis l’app.
Un traceur GPS compilé dans le code, prêt à s’activer
Le fichier de configuration Expo de l’application contient un plugin nommé « withNoLocation », censé supprimer le code de géolocalisation. Le problème : le pipeline complet de tracking GPS du SDK OneSignal est bel et bien compilé dans le binaire final. Le plugin n’a visiblement rien désactivé du tout.
L’analyse du code natif révèle un système à deux vitesses. En mode actif (application au premier plan), la position GPS est relevée toutes les 4 minutes 30 secondes. En arrière-plan, l’intervalle passe à 9 minutes 30 secondes. Latitude, longitude, précision, horodatage, état de l’application (premier plan ou arrière-plan), type de signal (GPS précis ou réseau approximatif) : tout est capturé et synchronisé vers les serveurs d’OneSignal.
Le tracking n’est pas actif par défaut. Trois conditions doivent être remplies : un appel JavaScript « setLocationShared(true) » côté app, l’accord de l’utilisateur via la permission Android, et la présence d’un fournisseur de localisation sur l’appareil. Mais l’intégralité de l’infrastructure est compilée et opérationnelle. Le développeur précise que les fonctions setLocationShared et isLocationShared sont référencées dans le bundle JavaScript de l’app, ce qui confirme que le code dispose de la capacité de l’activer. La fiche Google Play Store, de son côté, confirme que l’application demande « l’accès à la localisation précise uniquement au premier plan » et « l’accès à la localisation approximative uniquement au premier plan ».
Le code d’un inconnu sur GitHub exécuté dans l’app
Pour intégrer les vidéos YouTube, l’application utilise la bibliothèque react-native-youtube-iframe. Cette bibliothèque charge son lecteur HTML depuis un site GitHub Pages personnel, celui du compte « lonelycpp ». Si ce compte venait à être compromis, un attaquant pourrait injecter du code arbitraire qui s’exécuterait dans le contexte de navigation de chaque utilisateur de l’application.
Ce n’est pas la seule dépendance problématique. L’app charge du JavaScript tiers depuis Elfsight, une entreprise SaaS commerciale, pour afficher des flux de réseaux sociaux. Ce code tourne dans la WebView de l’application sans aucune isolation, et peut être modifié côté serveur à tout moment par Elfsight. Les emails d’inscription transitent par les serveurs de Mailchimp. Les images de contenu sont hébergées sur Uploadcare. Et un widget Truth Social est intégré en dur avec un bouton « Follow on Truth Social ».
Au total, 68 bibliothèques tierces sont compilées dans l’APK, dont Firebase Analytics, Google Data Transport et OpenTelemetry pour la télémétrie, ainsi que Google ML Kit Vision pour la lecture de codes-barres. 25 bibliothèques natives en .so sont incluses dans le split ARM64.
OneSignal collecte bien plus que des notifications push
Le SDK OneSignal, officiellement utilisé pour les notifications push, joue un rôle bien plus étendu dans l’application. L’analyse des chaînes de caractères extraites du bytecode Hermes révèle des fonctionnalités de segmentation utilisateur (addTag), d’association de numéros de téléphone aux profils (addSms), d’identification cross-device (addAliases) et de suivi de conversions (addOutcomeWithValue). L’ensemble du cycle de vie des messages in-app est tracé : affichage, clic, fermeture. Chaque changement d’état (permissions, abonnement, état utilisateur) est enregistré.
La base de données locale conserve chaque notification reçue et son statut (ouverte ou ignorée). Localisation, interactions avec les notifications, clics sur les messages in-app, numéro de téléphone si l’utilisateur le fournit, tags, changements d’état. Le tout est envoyé vers les serveurs d’OneSignal.
Pas de certificate pinning et des restes de développement
L’application utilise le TrustManager Android standard sans ajouter de certificate pinning. Sur un réseau Wi-Fi public ou un réseau d’entreprise avec proxy, le trafic entre l’app et ses serveurs peut être intercepté et lu par un tiers.
Le build de production contient aussi des vestiges de développement qui n’auraient jamais dû se retrouver dans une app publique. Une URL localhost (le serveur Metro de React Native) est codée en dur dans le bundle Hermes. L’adresse IP locale d’un développeur figure dans les ressources. Le client de développement Expo (expo-dev-client, expo-devlauncher, expo-devmenu) est compilé dans le build final, icône de menu développeur incluse.
Un backend WordPress et des chaînes de caractères révélatrices
Côté serveur, l’app s’appuie sur une API WordPress REST personnalisée (namespace whitehouse/v1), avec des points d’accès pour les articles, les diffusions en direct, les galeries photo, les priorités politiques et une section « Media Bias ». On trouve aussi un proxy pour le flux X/Twitter et un accès direct au formulaire de signalement de l’ICE (Immigration and Customs Enforcement), intégré dans ce qui se présente comme une app d’information.
Dans le bytecode, le développeur a relevé des chaînes codées en dur comme « THE TRUMP EFFECT », « Greatest President Ever! », « Text President Trump » et « Send a text message to President Trump at 45470 ». L’app sert donc autant de canal de communication politique que d’outil d’information.
Ce que cette analyse révèle sur les apps gouvernementales
Le développeur qui a mené cette rétro-ingénierie a suivi une méthode classique : extraction des APK avec ADB, décompilation avec JADX, analyse des chaînes dans le bytecode Hermes. Son rapport, exhaustif et technique, ne formule pas d’accusation de malveillance délibérée. Il constate des faits : une infrastructure de tracking compilée mais pas nécessairement activée, des dépendances tierces non auditées, et un contournement systématique des mécanismes de consentement web.
L’Agence américaine de cybersécurité (CISA) publie régulièrement des recommandations pour le développement d’applications gouvernementales, qui incluent le principe de « secure by design ». Charger du code depuis un GitHub Pages personnel ou compiler un client de développement dans un build de production ne figure dans aucune bonne pratique connue.
Pour les utilisateurs européens, la suppression automatique des bannières RGPD par une app officielle pose une question juridique inédite. Aucune autorité de protection des données n’a encore réagi à ces révélations, publiées samedi sur le blog thereallo.dev et largement relayées sur Hacker News.
