Clearing Cookies Did Not Break the Link. The Browser Called the App Through Localhost.
A web page and a native app are supposed to occupy different security contexts. Meta Pixel and Yandex Metrica turned Android’s localhost interface into a bridge between them, linking browser activity to identifiers held by Facebook, Instagram and Yandex apps.
The technique did not need a microphone, a browser exploit or a conventional Android sandbox escape. It used ordinary networking features in an unexpected combination: tracking JavaScript running on a website contacted a service listening on the same phone, then exchanged identifiers with the native app behind that service.
The activity stopped after researchers disclosed it publicly in June 2025. The completed study has now received the Internet Defense Prize and a Distinguished Paper Award at USENIX Security 2026. That recognition matters because the finding is larger than a single tracking incident. It exposes a gap in the assumption that browsers, apps, private-browsing sessions and mobile profiles are meaningfully separated.
Localhost became an identity bridge
Android historically allowed an app with the ordinary INTERNET permission to open a listening socket on the loopback interface. Mobile browsers could also connect to that interface without asking the user. Both behaviours have legitimate uses, but together they created an unmediated channel between JavaScript in a web page and a native app on the same device.
The researchers behind Local Mess found two implementations of this pattern. Meta Pixel used the channel to send a website-specific _fbp cookie into Facebook or Instagram. Yandex Metrica used localhost requests to obtain identifiers from Yandex apps and return them to browser JavaScript.
That distinction is important. The companies did not use identical protocols or data flows, but both crossed the same boundary: state that appeared to belong to a web context could be connected to longer-lived identity held by a native application.
Meta sent the web identifier into the app
Meta’s implementation used WebRTC traffic to UDP ports on the phone. Facebook and Instagram listened on a small range of fixed ports after a logged-in user had opened the app. When the user later visited a website containing Meta Pixel, the script could embed the site’s _fbp cookie in a WebRTC message and send it to the app over localhost.
The app then transmitted that cookie to Meta alongside persistent account-related identifiers. Separately, the Pixel sent the same _fbp value to Meta with the page URL, event type and browser metadata. Those two paths made it possible to associate a browser visit with the identity available to Facebook or Instagram.
The _fbp cookie is normally first-party state. A different value can be set under each site’s domain, which limits direct cross-site reuse. Connecting those separate values to the same logged-in app identity changes that privacy property. Clearing the cookie can remove the browser-side value, but it does not erase the native account to which earlier values were linked.
Yandex returned native identifiers to the browser
Yandex Metrica used HTTP and HTTPS requests to fixed local ports. Yandex Maps, Navigator, Search, Browser and other tested apps opened local web servers through the AppMetrica software development kit. The configuration, including which ports to use, could be retrieved from a Yandex-controlled endpoint.
When Metrica JavaScript ran in a mobile web page, it sent opaque parameters to the local service. The app returned an encrypted payload containing native identifiers. The script then forwarded that payload to Yandex’s backend with the web-tracking data.
The researchers did not infer the contents merely from obfuscated traffic. Their peer-reviewed USENIX paper describes static analysis and dynamic instrumentation used to intercept the payload before encryption. It included the Android Advertising ID, an AppMetrica UUID and other device identifiers. Historical web data indicated that Yandex had used localhost channels since 2017.
Incognito mode did not restore separation
Private browsing isolates or discards browser state. It does not normally stop an installed native app from recognising its logged-in user, nor did it prevent a page from contacting localhost in the tested browsers.
As a result, the demonstrated channels could work despite:
- clearing cookies and browsing data;
- using Incognito or private-browsing mode;
- resetting the Android advertising identifier;
- routing internet traffic through a VPN; or
- separating activity between Android work and personal profiles.
This does not mean private browsing is useless. It means its boundary ends at the browser. If a page can communicate with a native app through a channel the platform does not mediate, a browser-only privacy control cannot guarantee cross-context anonymity.
The communications often started before consent
The team crawled leading websites from European and US vantage points, both after accepting consent prompts and without interacting with them. In the European crawl, it observed Meta’s localhost communication on 15,677 sites and Yandex’s on 1,260. Without accepting consent, the behaviour still appeared on 11,890 Meta-integrating sites and 1,064 Yandex-integrating sites.
The researchers stress that the crawl was a representative measurement rather than an exhaustive inventory. It nevertheless shows why website owners cannot outsource consent compliance to a tag label or vendor reputation. A consent banner is ineffective if third-party code executes the sensitive behaviour before the choice is recorded.
The same opening created a second risk
The Yandex implementation used local HTTP requests that exposed the requesting page through the request’s origin information. The researchers built a proof-of-concept Android app that listened on the relevant ports and recorded sites visited in Chrome, Firefox and Edge, including private-browsing sessions.
They did not observe an unrelated app exploiting those ports in the wild. The result should therefore be described as a demonstrated capability, not a confirmed malware campaign. It still matters because it shows that the channel was not exclusively available to the intended analytics app. Any local app able to win the port race could potentially observe compatible traffic.
The tracking stopped, but the boundary problem remains
According to the researchers, Meta Pixel stopped sending localhost traffic on 3 June 2025 and most of the responsible code was removed. Yandex also discontinued the observed practice. Yandex said the feature supported personalisation, denied that it de-anonymised users and said it was removing the capability while discussing Play policy compliance with Google.
Browser vendors also reacted. Chrome 137 introduced targeted protections against the abused ports and Meta’s specific WebRTC technique. Firefox 139 blocked the ports involved. DuckDuckGo amended its blocklist, while Brave’s existing localhost permission and blocking behaviour prevented the tested flows.
Those are useful incident-specific mitigations. They are not a complete trust model.
Chrome’s broader Local Network Access design adds a permission prompt when a public website tries to contact a private-network or loopback destination. The USENIX researchers also identified additional paths that proposed protections need to consider, including global-unicast IPv6 addresses reached through WebRTC and mDNS names under .local. These were defense-evaluation findings, not evidence that Meta or Yandex used those particular bypasses.
Android is moving the control deeper into the operating system. Under Google’s current Android 17 model, apps targeting SDK 37 or later are blocked from local-network access by default and must request ACCESS_LOCAL_NETWORK. Legacy apps targeting an earlier SDK continue to receive implicit access for now, which makes target-version migration and enforcement part of the security outcome.
What site owners should do
The lesson for website operators is not limited to Meta Pixel or Yandex Metrica. Third-party JavaScript can gain new capabilities without the host website changing its own code.
- Inventory actual network behaviour. Record the domains, protocols, local-address requests and browser APIs used by analytics, advertising, fraud-prevention and tag-management scripts.
- Gate execution, not just cookies. Code that is not essential should not load until the relevant consent state exists. Preventing a cookie write while allowing the script to run may be insufficient.
- Retest after vendor changes. A tag can change between two page loads. Use controlled mobile testing and content-security telemetry rather than relying only on documentation.
- Review contractual assurances. Website owners need enough information from processors and advertising partners to describe the processing accurately and honour withdrawal of consent.
- Treat localhost as an external trust boundary. A request to
127.0.0.1,::1or a local name is not automatically harmless merely because the traffic never leaves the device directly.
What mobile and browser teams should do
- Audit applications and embedded SDKs for listening sockets, especially background services opened after launch or login.
- Test private-browsing and profile-separation claims against native-app communication, not only browser storage.
- Keep managed Android browsers current and verify whether localhost and Local Network Access protections are enabled in the deployed build.
- Prepare Android applications for the Android 17 local-network permission instead of delaying target-SDK migration.
- Monitor attempts by public web origins to contact loopback, private IPv4, local IPv6 and mDNS destinations.
What the evidence does and does not show
The study provides empirical evidence for Android. It did not find the same Meta or Yandex behaviour on the tested iOS devices. It documents identifier exchange and backend transmission, not microphone recording or audio capture. It also does not establish that every site embedding the affected analytics code intended the localhost behaviour or understood it.
The behaviour is no longer observed, but its consequences are still active. Spain announced an investigation into Meta in November 2025, and the work has informed browser changes, Android’s permission model, regulatory scrutiny and litigation.
The strongest conclusion is architectural: a security boundary is only as strong as every permitted channel that crosses it. The browser sandbox, the app sandbox, Incognito mode and profile separation all appeared intact when considered independently. Localhost connected them.
Sources
- USENIX Security 2026: Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost
- Local Mess technical disclosure, code, datasets and mitigation timeline
- Radboud University: USENIX awards and impact update
- Android Authority: Yandex statement following the disclosure
- Chrome for Developers: Local Network Access permission
- Android Developers: Local network permission and Android 17 enforcement
- Government of Spain: investigation into Meta’s Android tracking mechanism
