Vous pensiez avoir limité le tracking en refusant les cookies, en vidant votre historique et en activant la navigation privée ? Raté. Meta et Yandex ont contourné les règles d’Android pour faire dialoguer leurs scripts web avec leurs applications installées sur votre téléphone, de manière à relier votre historique de navigation à votre identité réelle. Et ce manège dure depuis des années.
- Meta et Yandex contournent les règles Android pour lier votre historique web à votre identité réelle.
- Leurs scripts exploitent des canaux internes Android, désanonymisant l'activité web sans consentement utilisateur.
- Google enquête, mais désinstaller les applications concernées reste la meilleure protection pour l'instant.
En théorie, Android et les navigateurs modernes sont conçus pour empêcher le suivi transversal entre sites, applications et identités réelles. En pratique, Meta et Yandex ont délibérément contourné ces limites. D’après une enquête menée par le collectif Local Mess – un groupe de chercheurs affiliés à plusieurs universités européennes –, leurs scripts de tracking, Meta Pixel et Yandex Metrica, exploitent des canaux internes au système Android pour transmettre des identifiants de navigation à leurs applications mobiles. Un dispositif pernicieux mis en place pour forcer la désanonymisation, en liant l’activité web à un profil personnel sans que l’utilisateur ou l’utilisatrice n’en soit jamais informé. Évidemment.
Le Meta Pixel, le navigateur et l’appli : anatomie d’une désanonymisation non consentie
Pour rappel, le Meta Pixel est un outil publicitaire intégré à des millions de sites web. Il mesure les actions des visiteurs – clics, vues, achats – puis envoie ces données à Meta pour améliorer le ciblage publicitaire sur Facebook et Instagram. Lorsque vous êtes connecté à l’un ou l’autre de ces réseaux sociaux dans votre navigateur, le lien entre votre visite et votre compte est facile à faire. Dans le cas contraire, les données restent liées à un identifiant pseudonyme, stocké dans un cookie (_fbp).
En principe, cet identifiant ne permet pas de savoir qui vous êtes. Il est propre à chaque navigateur, isolé site par site, et disparaît lorsque vous supprimez vos cookies. Mais sur Android, Meta a trouvé un moyen de contourner ces limites. Selon les chercheurs à l’origine de l’enquête, depuis septembre 2024, le Meta Pixel ne se contente plus d’envoyer le cookie _fbp à ses serveurs : il le transmet aussi, en parallèle, à l’application Facebook ou Instagram installée sur le téléphone, en abusant de l’interface de communication locale du système.
Concrètement, Meta exploite activement le protocole WebRTC, normalement utilisé pour les appels audio ou vidéo entre navigateurs. Grâce à une technique appelée SDP munging (qui consiste à modifier manuellement les paramètres d’une connexion pour y insérer des données arbitraires, comme ici un identifiant de suivi), le script glisse discrètement le cookie _fbp dans la requête envoyée à l’adresse locale de l’appareil (127.0.0.1). Or, les applications Facebook et Instagram, même si elles ne font que tourner en arrière-plan, sont configurées pour écouter ce type de trafic. Elles ouvrent pour cela des ports réseau locaux (notamment dans la plage 12580–12585) afin de recevoir ces requêtes entrantes depuis le navigateur. Dès qu’elles les captent, elles en extraient l’identifiant pseudonyme.
Et c’est ici que la situation prend une tournure autrement problématique. Car ces applications, déjà connectées à un compte utilisateur, peuvent recouper ce cookie pseudonyme avec des identifiants persistants accessibles depuis le système : identifiant publicitaire Android (AAID), ID de session Meta, voire d’autres marqueurs propres à l’appareil.
L’ensemble est ensuite envoyé aux serveurs de Meta, qui peuvent alors faire le lien entre votre navigation web et votre profil personnel, et, au fil des visites sur les sites intégrant son pixel, reconstituer votre historique de navigation détaillé. Même si vous n’êtes pas connecté dans le navigateur. Même si vous utilisez la navigation privée. Même si vous avez refusé les cookies. Même si les applis Facebook et Instagram ne sont pas ouvertes.
En d’autres termes, les barrières censées cloisonner l’activité web et l’identité mobile sautent. Le navigateur n’est plus un espace isolé, mais une passerelle qui transmet les données de navigation à l’application. Un processus que les chercheurs décrivent comme une « rupture du modèle de sandboxing » entre le navigateur et le système.
Yandex, même recette, autre méthode
Yandex mise sur une approche comparable, suivant une mécanique un peu différente. Depuis 2017, le script de suivi Yandex Metrica, présent sur de nombreux sites, envoie des requêtes HTTP ou HTTPS à des ports Android locaux spécifiques (comme 29009 ou 30102), là aussi ouverts en arrière-plan par les applications Yandex. Lorsqu’elles reçoivent ces requêtes, les applications Yandex – Maps, Navigator, Browser, etc. – renvoient des identifiants tels que l’AAID ou d’autres valeurs uniques. Le script intégré au site récupère ensuite ces données et les transmet aux serveurs de Yandex. Dans ce cas, c’est le navigateur qui termine le travail, en transférant les identifiants fournis par l’application au service de tracking.
Mais l’effet est le même : les protections classiques ne fonctionnent plus, et les internautes n’ont aucun moyen d’en être informés ni d’y consentir explicitement. Et comme chez Meta, la désanonymisation est automatique : chaque visite web peut être rattachée à un utilisateur ou une utilisatrice spécifique, avec une précision nettement supérieure à celle des cookies.
Comble de la perversité, certaines entreprises ayant intégré ces scripts ont découvert le pot aux roses en tombant sur des erreurs JavaScript liées à des connexions vers l’adresse 127.0.0.1, sans savoir ce qui s’y passait réellement. Évidemment, côté Meta comme Yandex, aucune documentation officielle ne décrit ce fonctionnement.
Un angle mort d’Android exploitable à grande échelle
Ce type de contournement ne repose ni sur une faille critique ni sur un bug, mais sur un comportement structurel d’Android. Le système permet à n’importe quelle application disposant de l’autorisation « Internet » – ce qui est quasiment toujours le cas – d’écouter du trafic réseau sur l’adresse locale 127.0.0.1 sans restriction, en ouvrant librement des ports réseau internes.
Dans le même temps, les navigateurs sont libres d’y envoyer des requêtes, sans en informer l’internaute ni exiger de consentement explicite. En bref, un angle mort du design d’Android que Meta et Yandex n’ont eu aucun scrupule à exploiter – et qui pourrait tout aussi bien l’être par d’autres applications, y compris malveillantes. Car sur Android, le trafic envoyé à 127.0.0.1 n’est pas cloisonné : n’importe quelle app autorisée à accéder à Internet peut intercepter ou détourner les données destinées à une autre.
Pendant des mois, les principaux navigateurs Android – Chrome, Edge, Firefox – ont exécuté les scripts concernés sans bloquer ce type de comportement. Seuls Brave et DuckDuckGo filtraient déjà les connexions aux ports locaux sensibles ou les domaines connus pour ce genre d’usage. Ce n’est que fin mai 2025 que Google a intégré un correctif dans Chrome 137 pour bloquer certains ports et limiter les abus liés à la modification des messages SDP dans WebRTC (le fameux « SDP munging »). Quelques jours plus tard, Meta modifiait déjà son script pour contourner ces nouvelles mesures de protection.
C’est justement ce jeu de chat et de souris qui inquiète les chercheurs. Les blocages actuels reposent sur des listes noires et des patchs ciblés, faciles à contourner. Changer de port, modifier un champ de requête, utiliser une autre interface locale : il suffit de peu pour relancer le dispositif. D’après eux, seule une refonte du modèle de communication locale sur Android permettrait d’éviter durablement ce type de détournement, en limitant l’accès aux ports internes ou en imposant des permissions explicites.
Selon Ars Technica, Google a indiqué avoir ouvert une enquête, estimant qu’un tel comportement violait les politiques de confidentialité et de transparence imposées aux applications Android publiées sur le Play Store. Meta, de son côté, affirme avoir « suspendu la fonctionnalité »… le jour même de la publication du rapport des chercheurs. Aucune précision n’a été donnée sur sa durée d’activation ni sur le sort des données collectées, et aucun des deux acteurs n’a communiqué sur une éventuelle notification aux utilisateurs ou utilisatrices concernés.
En l’état actuel des choses, la seule protection réellement efficace reste donc encore de désinstaller les applications concernées.
Source : Local Mess, Ars Technica
