Révélation d’une technique furtive de suivi web-app sur Android via localhost

• Il a été révélé que de grandes applications comme Meta (Facebook) et Yandex utilisaient des ports locaux (127.0.0.1) sur Android pour partager secrètement des identifiants et des cookies entre le navigateur web et les applications natives
• Des scripts Facebook Pixel et Yandex Metrica intégrés aux sites web transmettaient directement, depuis le navigateur Android vers les applications natives (Facebook, Instagram, applications de l’écosystème Yandex), des sessions de navigation et des identifiants, permettant l’identification et la désanonymisation des utilisateurs
• Cette méthode contourne toutes les protections de confidentialité existantes, y compris la suppression des cookies, le mode privé, les réglages d’autorisations et la réinitialisation de l’identifiant publicitaire ; si une application malveillante écoute simplement le bon port, elle peut aussi collecter l’historique de navigation
• Après la divulgation du 3 juin 2025, Facebook a supprimé l’essentiel du code concerné, mais cette technique a été utilisée pendant des années sur des centaines de millions d’appareils Android dans le monde. Yandex continue d’employer une méthode similaire depuis 2017
• Les principaux navigateurs comme Chrome, Firefox et Brave ont mis en place des blocages d’urgence, mais en raison de limites structurelles de la plateforme, aucune réponse de fond complète n’existe encore, ce qui souligne la nécessité de renforcer la sécurité de l’IPC Android et du réseau local

---

Disclosure: technique furtive de suivi web-app via localhost

• Les chercheurs ont découvert que Meta et Yandex visaient des milliards d’utilisateurs Android, en laissant des applications natives écouter en arrière-plan sur des ports locaux prédéfinis (par ex. 12580~12585, 29009~30103) pour communiquer avec du JavaScript exécuté sur le web
• Cela permet de transmettre à l’application native les cookies, métadonnées et historiques d’usage du navigateur web, puis de les combiner avec les informations du compte de l’application et l’Android Advertising ID afin de lier l’identité de l’utilisateur à ses visites web

How does this work?

Exploitation des ports locaux d’Android

• Sur Android, toute application disposant uniquement de l’autorisation INTERNET peut ouvrir un socket sur 127.0.0.1 (loopback)
• Le navigateur peut lui aussi accéder à cette interface sans consentement spécifique de l’utilisateur
• Du JavaScript intégré à un site web peut échanger des données entre le navigateur et l’application native via des Web API standard

Mode de liaison web-app de Meta/Facebook Pixel

• Quand le JavaScript Meta Pixel est chargé dans un navigateur Android, il envoie la valeur du cookie _fbp à l’application native via des paquets STUN WebRTC (UDP ports 12580–12585)
• Les applications Facebook et Instagram présentes sur l’appareil (selon les versions, par ex. 515.0.0.23.90/382.0.0.43.84) écoutent sur ces ports, reçoivent la valeur _fbp envoyée par le navigateur, puis la transmettent à leurs propres serveurs via GraphQL
• _fbp est un cookie majeur intégré à environ 25 % du premier million de sites ; auparavant il était isolé par site, ce qui rendait le suivi croisé difficile, mais cette méthode permet d’associer plusieurs valeurs _fbp d’un même utilisateur à un seul compte
• Depuis mai 2025, une méthode WebRTC TURN a en outre été ajoutée, et le script a été modifié pour éviter la technique de SDP Munging
• Le cookie _fbp est conservé 90 jours et est extrêmement courant, au point d’être utilisé sur 25 % des principaux sites web
• Après les contre-mesures de navigateurs majeurs comme Chrome, le code a été supprimé le 3 juin

Mode de liaison web-app de Yandex Metrica

• Le script Yandex Metrica envoie depuis 2017 des requêtes HTTP(S) vers des ports locaux (29009, 29010, 30102, 30103, etc.)
• Des applications Yandex (Yandex Maps, Navigator, Browser, Search, etc.) gardent ces ports ouverts et répondent aux requêtes reçues avec des données contenant l’Android Advertising ID (AAID) encodé en Base64, ainsi que d’autres identifiants d’appareil, UUID, etc.
• Le script du navigateur collecte ces informations puis les renvoie aux serveurs de Yandex, ce qui complète la liaison d’identifiants entre navigateur, application et serveur
• Le domaine yandexmetrica.com est résolu vers 127.0.0.1 pour éviter la détection et masquer le flux de collecte
• En raison de l’utilisation de HTTP sur localhost, si une autre application écoute sur le même port, il existe aussi un risque d’exposition de l’historique de visite des sites web de l’utilisateur

Risque concret : fuite de l’historique de navigation

• En cas de communication locale basée sur HTTP, n’importe quelle application Android peut obtenir l’historique, y compris les URL visitées, si elle écoute simplement sur le port concerné
• Le développement d’une application Proof-of-Concept et des tests sur Chrome, Firefox et Edge ont démontré que la navigation privée et le mode incognito sont eux aussi vulnérables
• Seuls certains navigateurs, comme Brave et DuckDuckGo, ont pu se défendre via leur propre liste de blocage et l’exigence du consentement utilisateur

Affected Sites

• Meta Pixel : utilisé sur 5,8 millions de sites web ; d’après des résultats de crawl réels, un partage d’identifiants locaux a été observé sur 15 000 sites dans l’UE et 17 000 sites aux États-Unis parmi les 100 000 premiers sites
• Yandex Metrica : utilisé sur 3 millions de sites web ; avec la même méthode, une communication avec les ports locaux a été confirmée sur 1 260 sites de l’UE et 1 312 sites des États-Unis
• Une part importante de ces sites lance le suivi automatiquement même sans procédure de consentement aux cookies

History

• Yandex : utilisation de ports HTTP/HTTPS depuis 2017
• Meta : HTTP en septembre 2024, WebSocket en novembre 2024, WebRTC STUN en 2025, puis transition progressive vers TURN en mai

Abuse Vectors

• La cause principale est l’absence de restriction d’accès aux sockets localhost sur Android ainsi que des politiques de sandbox insuffisantes
• Les réglages d’autorisations existants, le mode privé du navigateur, la réinitialisation de l’identifiant publicitaire et toutes les autres protections sont contournés
• Il reste difficile de distinguer ces usages d’usages légitimes destinés au développement web, mais cela constitue un cas avéré de suivi à grande échelle
• Des navigateurs comme Chrome, Firefox, DuckDuckGo et Brave déploient des correctifs d’urgence, mais au fond un renforcement des autorisations, des avertissements utilisateur, du sandboxing et des politiques IPC au niveau de la plateforme est nécessaire

Disclosure

• Une divulgation responsable et une coopération ont été demandées aux éditeurs de navigateurs comme Chrome, Firefox, DuckDuckGo et Brave
• Des mesures de court terme ont été appliquées dans Chrome (version 137), Firefox (version 138), Brave, etc., comme le blocage des ports vulnérables et de SDP Munging
• À long terme, le besoin de correctifs structurels comme le contrôle d’accès au réseau local, un sandbox renforcé et une meilleure information des utilisateurs est mis en avant

Navigateur	Version	Yandex	Facebook	État de la réponse / du blocage
Chrome	136.0+	Affecté	Affecté	À partir de la 137, blocage des ports et du SDP munging, déploiement progressif
Edge	136.0+	Affecté	Affecté	Non clair (basé sur Chromium)
Firefox	138.0.2	Affecté	Non affecté(1)	Blocage du SDP munging, blocage de l’UDP prévu ultérieurement
DuckDuckGo	5.233.0	Partiellement affecté(2,3	Non affecté(2,3)	Blocage basé sur une blocklist
Brave	1.78.102	Non affecté(3,4)	Non affecté(3,4)	Depuis 2022, consentement utilisateur requis pour les requêtes localhost, blocklist appliquée

• 1 : SDP Munging bloqué, ports TURN pas encore bloqués (application prévue ultérieurement)
• 2,3,4 : diverses défenses comme blocklist, blocage de ports et consentement utilisateur

Niveau de connaissance chez les utilisateurs et opérateurs

Exploitants de sites

• Cette méthode n’a jamais été rendue publique dans la documentation officielle de Meta ou de Yandex
• Depuis septembre 2024, des questions se sont multipliées sur les forums développeurs Facebook du type « pourquoi le script Pixel accède-t-il à localhost ? », sans aucune réponse officielle
• Les exploitants de sites et les utilisateurs finaux n’en ont généralement pas connaissance. Le suivi reste possible même si l’utilisateur n’est pas connecté, est en mode incognito ou a supprimé ses cookies

Utilisateurs ordinaires

• Le suivi fonctionne indépendamment de l’état de connexion
• Le mode incognito, la suppression des cookies et les autres protections sont neutralisés
• De nombreux cas montrent que cela fonctionne aussi sur des sites sans procédure de consentement aux cookies

Résumé de la FAQ

• Q : Pourquoi Meta a-t-il arrêté cette méthode immédiatement après sa divulgation ?
  R : Aucune réponse officielle ; il a été confirmé qu’après la divulgation, l’envoi de paquets aux utilisateurs Android a cessé
• Q : La recherche a-t-elle été peer-reviewed ?
  R : Elle a été vérifiée par certaines institutions, mais avant l’évaluation académique formelle, une divulgation rapide a été décidée en raison de l’ampleur potentielle des abus
• Q : Cette méthode est-elle documentée dans les documents officiels de Meta/Yandex ?
  R : Il n’existe pas de documentation technique officielle ; seules des questions sur les forums développeurs existent
• Q : iOS ou d’autres plateformes sont-ils également affectés ?
  R : Cela n’a été confirmé que sur Android à ce jour, mais techniquement iOS, le desktop ou les smart TV pourraient aussi présenter un risque potentiel

[dhy0613]

Comme la batterie se vidait bizarrement très vite, j’avais supprimé toutes les apps de Meta ; donc c’était bien ça… Je vais aussi devoir supprimer via adb le reste des apps système intégrées sur mon Galaxy.

[savvykang]

Moi non plus, je n’arrive pas à faire confiance à l’app Meta, donc je ne l’utilise pas et je passe uniquement par Chrome dans le dossier sécurisé.

[iolothebard]

La plupart des frameworks dits d’applications web hybrides lancent un serveur web sur localhost (même si le but est différent). L’idée est de gérer, côté serveur web lancé sur localhost (partie native), des choses (partie web) qui ne peuvent pas être résolues via la configuration de la bibliothèque de navigateur intégrée (WebKit…) ou même avec des personnalisations. On pouvait aussi l’exploiter comme ça… quel gâchis

[jeiea]

À mon avis, dans une application hybride, la méthode classique de communication entre le web et l’app passe par les API fournies au niveau de l’OS et du navigateur, qu’on appelle aussi des bridges. Je ne pense pas qu’un serveur web local soit indispensable.
Si l’usage d’un serveur web local a posé problème ici, c’est probablement parce qu’il peut permettre des vulnérabilités comme le fait d’accéder à un port localhost depuis Chrome en mode secret et de compromettre ainsi l’anonymat de l’utilisateur. Si cette technique est indispensable dans les applications hybrides... alors ce sont les applications hybrides qui doivent disparaître.

[nemorize]

Il est assez courant d’ouvrir un serveur web dans l’application pour gérer des fonctionnalités qui imposent un nom de domaine, comme localStorage, entre autres.

[ethanhur]

Si je ne paie pas pour un service, c’est que je suis le produit. Les tentatives pour suivre toujours davantage les individus à travers les données vont se multiplier, et il ne semble pas possible d’inverser cette tendance. Il nous faudrait une meilleure alternative, mais sous le capitalisme, je vois mal à quoi elle pourrait ressembler.

[savvykang]

Je me demande si l’accès à localhost entre l’intérieur et l’extérieur du Dossier sécurisé sur les Galaxy est bien isolé.

[savvykang]

Il n’y a donc pas d’isolation. En lançant le serveur Python http.server via Termux à l’extérieur du Dossier sécurisé, puis en y accédant depuis Chrome à l’intérieur, la connexion fonctionne.

[forgotdonkey456]

N'est-ce pas une faille de sécurité ? -_-??

[jjpark78]

La bonne réponse, c’est sans doute de ne pas utiliser les réseaux sociaux...

[GN⁺]

Avis Hacker News

• Si je résume le processus global de tracking utilisé par Meta tel que je l’ai compris, en m’appuyant sur le blog Localmess

  1. Quand l’utilisateur est connecté à l’app Facebook ou Instagram, l’app écoute en arrière-plan le trafic entrant sur un port spécifique
  2. Quand l’utilisateur visite un site web sur le navigateur de son téléphone (p. ex. something-embarassing.com), ce site a souvent Meta Pixel intégré (l’article dit qu’il est installé sur plus de 5,8 millions de sites)
     Le suivi reste possible même en mode navigation privée
  3. Selon l’endroit, le site peut demander le consentement de l’utilisateur ; l’article ne le détaille pas, mais cela semble probablement désigner ces « bannières cookies » que beaucoup acceptent machinalement
  4. Le script Meta Pixel envoie le cookie _fbp (qui contient des informations de navigation) à l’app Instagram ou Facebook en utilisant la technique WebRTC (STUN) dite SDP Munging
     Cette partie du processus n’apparaît même pas dans les outils de développement du navigateur
  5. Si l’utilisateur est déjà connecté dans l’app, Meta peut relier cette activité de navigation « anonyme » au profil connecté
     L’app transmet ensuite les informations _fbp et l’ID utilisateur aux serveurs de Meta
     Autres points notables :

  • cette méthode de partage d’identifiant du web vers l’app contourne les protections de confidentialité classiques comme la suppression des cookies, le mode privé ou les contrôles de permissions Android

  • elle ouvre même la possibilité pour des apps malveillantes d’espionner l’activité web des utilisateurs

  • depuis la mi-mai, le script Meta Pixel a aussi commencé à envoyer le cookie _fbp via WebRTC TURN ; cette méthode a été introduite après que l’équipe Chrome a bloqué le SDP Munging

  • au 2 juin 2025, aucun comportement montrant que les apps Facebook/Instagram reçoivent réellement quoi que ce soit sur ce nouveau port n’a été observé

  • Si l’usage principal de WebRTC est de récupérer des informations comme l’IP locale de l’utilisateur pour le désanonymiser, je ne comprends pas pourquoi ce genre de fonctionnalité peut s’exécuter sans demande d’autorisation séparée

  • Selon le pays, visiter un site comme something-embarassing.com peut avoir des conséquences bien plus graves qu’un simple embarras

  • Je n’ai pas tout saisi, mais je me demande si cela inclut aussi une exploitation des avis obligatoires de consentement GDPR sur les cookies pour suivre les gens en secret

• J’aimerais simplement interdire la publicité et le tracking sur Internet
  Ça produit beaucoup trop de choses inutiles
  À mes yeux, tout ça existe juste pour que des CEO puissent s’acheter un yacht de plus

  • Reddit fait aussi beaucoup de fingerprinting d’appareil
    Et vend ces données pour l’entraînement de modèles d’IA
    Je m’attends à ce qu’un jour ils vendent activement même des données privées accessibles uniquement depuis les apps premium

  • Reste la question de savoir comment interdire ça, et comment prouver qui a enfreint la loi

  • Le mouvement visant à expulser les cookies tiers des navigateurs était en pratique la première étape la plus réaliste
    Mais Google a fait dérailler tout ça l’an dernier en profitant de sa domination sur Chrome
    Ce n’est peut-être pas illégal, mais c’est une manipulation de marché non éthique qui aurait dû provoquer la colère des consommateurs
    On dirait que les dirigeants de Google croyaient au départ pouvoir maintenir les revenus sans cookies ; en réalité, soit ils n’ont jamais compris ce que les cookies représentaient, soit ils n’ont jamais eu l’intention de les supprimer

  • Ce type de comportement relève de la pure cupidité
    Pendant des siècles, les dirigeants traditionnels qui ont réussi évitaient ce genre d’obsession excessive pour leur intérêt personnel
    Même des leaders simplement corrects peuvent généralement diriger leur entreprise mieux que ça en s’élevant au-dessus de ce niveau de bassesse
    Mais dans un monde où seule la cupidité subsiste, il ne reste qu’à en rire
    Ce serait bien d’avoir des CEO plus honnêtes et plus compétents

  • Pour rebondir sur la blague du « yacht du CEO », la plupart des consommateurs choisissent en réalité le modèle publicitaire parce qu’ils aiment les services/produits gratuits
    Quand il existe une version payante et une version avec publicité, la version financée par la pub l’emporte typiquement à 10 contre 1
    Le blocage publicitaire empire même la situation — la vraie résistance devrait être le boycott du service ou le paiement direct d’alternatives
    Une structure comme BAT (Brave Attention Token), qui redistribue directement de petits paiements aux sites, me paraît plus rationnelle
    En théorie, l’idée est : je paie pour ce que j’utilise, et je deviens un vrai client plutôt que le produit vendu aux annonceurs

• Rapport de problème réel : blog Localmess
  Google dit enquêter sur les cas d’abus, mais paradoxalement Google lui-même suit déjà tout le monde via divers canaux latéraux comme les noms de points d’accès Wi‑Fi
  Les grandes entreprises d’apps continuent de collecter des données par des moyens similaires pour contourner les restrictions de l’OS

• Une raison de plus de ne pas installer les apps des géants de la tech, et de n’utiliser leurs sites web qu’en cas de nécessité
  Les sites sont plus lents et moins pratiques, mais grâce au sandboxing ils sont bien plus sûrs

  • On ne sait pas clairement quelle app Meta ouvre le port
    Sur les téléphones Samsung, par exemple, plusieurs apps Meta sont préinstallées, et même si l’on supprime l’app Facebook, des services cachés comme com.facebook.services peuvent rester présents
    Ces services ne peuvent être supprimés qu’avec des outils de développeur (ADB/UAD)
    Sinon, mieux vaut prendre un iPhone ou un Pixel

• Informations techniques sur le script Meta Pixel :
  Meta Pixel transmettait via HTTP jusqu’en octobre 2024, et les apps Facebook/Instagram restent encore aujourd’hui en écoute sur ce port
  Elles écoutent aussi sur le nouveau port 12388, mais aucun script envoyant des données vers ce port n’a encore été trouvé
  Cela soulève une question scientifique (?) : une autre app pourrait-elle envoyer de faux messages sur ce port ?

  • À mon avis, il y a deux façons de perturber ces trackers
    La première consiste à ne rien envoyer du tout, la seconde à envoyer beaucoup de fausses données
    J’aimerais bien voir aussi un appareil qui partage les cookies de tracking publicitaire en P2P

• Je me demande si ce tracking peut traverser les profils
  Si oui, c’est un énorme problème de sécurité pour les entreprises
  En testant avec une app userland lançant un serveur sur le port 8080, j’ai constaté que les deux profils pouvaient y accéder
  Cela signifie qu’une app compromise dans un profil pourrait échanger des données avec des sites visités depuis l’autre profil

  • Cela dit, n’est-ce pas seulement possible lorsque le site communique explicitement avec un service lié à un port local sans authentification ?

• Si un particulier collectait des informations depuis l’ordinateur d’autrui de cette manière, je me demande si cela pourrait être puni au titre du CFAA (Computer Fraud and Abuse Act)

  • Cette méthode exige un contrôle du code des deux côtés : d’un côté le site visité, de l’autre l’app qui tourne sur le téléphone
    Ce n’est pas une technique de piratage magique permettant d’exfiltrer arbitrairement l’historique du navigateur
    Donc c’est difficile à qualifier clairement de piratage, et même si Google ou Meta pratiquent du tracking sans consentement, cela ne relèverait probablement pas du CFAA

  • En réalité, des gens ont déjà été poursuivis au titre du CFAA pour avoir simplement utilisé « afficher le code source » dans leur navigateur
    On dirait que ce qui compte n’est pas tant l’acte lui-même que la personne visée, le réseau et les relations de pouvoir

  • Il y a peut-être matière à sanction

• Ce système d’identifiants était beaucoup trop facile à détourner, et je suppose que Google le savait et savait aussi qu’il fallait impérativement définir des règles anti-abus
  C’est un sujet qui pourrait entraîner des sanctions allant jusqu’au bannissement permanent du Play Store, des poursuites judiciaires, voire des plaintes pénales
  Mais dans la pratique, quand l’entreprise est aussi grosse que Meta, il devient presque impossible d’imposer de vraies sanctions
  (Et même si ce n’était pas Meta, il est possible que ce genre d’activité suspecte bénéficie d’une approbation tacite des services de renseignement ou des forces de l’ordre — il est très difficile d’y mettre fin, et même d’en parler)

  • Google et Apple possèdent l’ensemble du système d’exploitation
    Ils ont eux-mêmes plus de cinquante façons de faire du tracking
    D’autres entreprises gagnent aussi beaucoup d’argent en renégociant avec les grands groupes des clauses de partage des données utilisateurs
    Les accords sont déjà passés, les autorisations déjà obtenues, et le seul problème serait que quelques utilisateurs fassent du bruit à ce sujet

• Dans Firefox, on peut bloquer WebRTC en passant l’option media.peerconnection.enabled à false dans about:config
  En combinant Netguard et Nebulo en mode non-VPN, on peut empêcher des connexions inutiles aux serveurs de Meta

• L’Union européenne devrait, à mon avis, infliger des amendes d’un niveau record pour ce genre de problème
  On pourrait aussi instaurer une taxe progressive augmentant de 1 à X % à chaque récidive
  Il faudrait en parallèle un site web permettant de voir d’un coup d’œil les infractions de chaque entreprise

  • Meta paie déjà des amendes chaque année tout en enregistrant environ 70 milliards de dollars de bénéfice net

  • Au-delà des amendes, des mesures plus fortes seraient aussi nécessaires dans certains cas, sachant que des particuliers ont déjà été emprisonnés pour des infractions bien plus mineures