Meta Pixel
Désanonymisation forcée : comment Meta et Yandex ont exploité une faiblesse Android pour relier votre historique web à votre vraie identité.
Vous pensiez avoir limité le tracking en refusant les cookies, en vidant votre historique et en activant la navigation privée ?
Raté. Meta Pixel et Yandex Metrica ont délibérément 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. Ce manège dure depuis des années.
—
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.
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.
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.
Les applications Facebook et Instagram, 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.
—
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.
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.
(lire l'article complet pour plus de précisions)