Naughty Meta Was Tracking Users

Meta’s mobile web tracking method—using localhost communication to bridge browser activity to native Facebook and Instagram identities—has been linked to potential EU regulatory penalties totaling up to €32 billion. The core claim is that Meta can identify users across web browsing sessions even when they use incognito mode, refuse or delete cookies, and even when a VPN is in place. The mechanism matters because it bypasses ordinary Android browser isolation expectations, turning “web-only” activity into something that can be tied back to long-lived app identifiers.

The described workflow starts when a user opens a native Facebook or Instagram app, which runs in the background and listens on specific TCP and UDP ports. When the user later visits a website that embeds the Meta Pixel script, the browser-side JavaScript attempts to communicate with the native app through localhost. That exchange carries the Facebook cookie (FBP) and browsing context—such as the visited URL and event types like page view, add to cart, or purchase—along with browser metadata. The native app then forwards the identifier to Meta’s servers using GraphQL mutations, effectively linking web activity to the user’s Facebook/Instagram account even if the user never logged into those accounts from the browser itself.

Researchers also report that Meta’s approach can evade standard user controls. The method is framed as bypassing Android sandbox protections and typical privacy expectations like clearing cookies or relying on incognito mode. A key detail is that the data flow is difficult to observe with common browser debugging tools because the communication rides on WebRTC/STUN-related traffic and UDP-based localhost messaging rather than straightforward HTTP requests.

Meta’s implementation has reportedly changed after disclosure. As of June 3rd, Meta Pixel is said to have stopped sending packets to localhost, with code responsible for cookie transmission “almost completely removed.” The transcript also notes that around May 17th Meta added a new method using TURN instead of STUN/related handling, with the claim that it avoids a technique Chrome developers publicly disabled following earlier disclosure.

The same localhost-bridging pattern is described for Yandex, via Yandex Metrica scripts embedded on millions of sites. Yandex-owned apps (including Yandex Maps, Yandex Navigator, and Yandex Search, plus a Yandex browser) are said to listen on local ports and act as a proxy that collects Android advertising identifiers and other app-accessible identity data. The Yandex Metrica domain is described as resolving to the loopback address, and the apps then upload aggregated identifiers back to Yandex servers.

Beyond tracking, the transcript raises an additional risk: malicious apps could potentially harvest browsing history by racing to listen on the same localhost ports and intercepting the HTTP requests used in Yandex’s flow. A proof-of-concept is described as demonstrating browsing-history leakage across Chrome, Firefox, and Edge, while Brave is said to be unaffected due to blocking behavior and DuckDuckGo only minimally affected.

Finally, the transcript situates the issue in scale and incentives. Meta Pixel is reported as embedded on millions of websites, and Yandex Metrica on close to three million. The broader takeaway is that “first-party” cookie use and incognito protections may not prevent identity linkage when web-to-app bridging is used, and that regulatory enforcement could hinge on whether multiple EU regimes—GDPR, DMA, and DSA—can apply cumulative penalties for the same underlying conduct.