Meta Fucking Spy Technique (Machine Translation Version)

June 6, 2025 · 8 min · 1620 words · gorn | Translations:

Ja

| Suggest Changes

The news sent chills down my spine.

Meta and Yandex are de-anonymizing Android users’ web browsing identifiers

Web browsers usually have a security feature called Same-Origin Policy (Same-Origin Policy), which severely restricts resource sharing between different origins (protocol, host and port combinations) Cross-Origin Resource Sharing (CORS) is a mechanism to mitigate this restriction, but requires explicit permission.

This section describes how Meta Pixel bypassed this restriction, based on the latest findings.

Exploitation of localhost sockets and WebRTC

The main modus operandi by which Meta Pixel bypassed the Cross-Origin restrictions was through a combination of.

use of localhost ports:.

Android apps provided by Meta (e.g. Facebook, Instagram) were silently listening on certain local ports in the device (e.g. 12580-12585). This means that the apps were ready to accept communications from the website.

Meta Pixel JavaScript code embedded in the website attempted to communicate to these ports on localhost (127.0.0.1) when executed on the mobile browser.

The communication to localhost was made outside the scope of, or exploited holes in, the browser’s same-origin policy. Browsers may be relatively less restrictive on communication to localhost within their own devices.

use of WebRTC (Web Real-Time Communication):.

Meta Pixel used a real-time communication protocol called WebRTC to send tracking data such as _fbp cookies (first-party cookies that identify the browser) to the localhost app. WebRTC is a technology that enables direct communication between browsers and between browsers and devices in the local network, and its functionality was abused for this tracking. In particular, the SDP (Session Description Protocol) part of WebRTC, which exchanges session information, was reportedly used (SDP munging).

data linkage on the app side:.

The Android app linked the _fbp cookie received via localhost to a persistent identifier (e.g. Facebook ID) of the user logged into the app.

This allows users to delete cookies in their browsers, use incognito mode or log in to Facebook/Instagram without their web browsing history being linked to their Meta user account and tracked, thus circumventing traditional privacy-preserving mechanisms have been implemented to circumvent this.

Responsibility of Meta and site operators

In fact, a check of the research report ‘Disclosure: Covert Web-to-App Tracking via Localhost on Android’ reveals the following list of websites using Meta Pixel on Japanese domains alone The following list of Japanese domains alone reveals the devastation caused by the use of Meta Pixel. This is only a small part of the story.

This situation shows that not only Meta, but also the site operators have a heavy responsibility**.

In view of this devastation, I urge the following.

First, **Meta must destroy all the data it has illegally collected so far. **
Secondly, ** the site operator must destroy all illegal data received from Meta. **

These are the minimum measures required to protect the privacy of users.

Rakuten ad4U

Meta Pixel’s modus operandi is reminiscent of the former Rakuten ad4U. Rakuten ad4U was also a type of behavioural targeting advertising, in which links to thousands of URLs were embedded in Adobe Flash objects, and each URL was checked for signs of having been visited using CSS colouring.

Rakuten ad4U’s modus operandi is detailed in User style sheet to expose Rakuten ad4U’s hidden links.

Of course, Meta Pixel’s modus operandi is far worse and more sophisticated than Rakuten’s. It is easy to see how “dark passions” have been poured into subverting browser security.

Browser vendor countermeasures: the unstoppable wrangling

Following the revelation of this hidden tracking method, major Android browser vendors have introduced or are developing patches to mitigate the problem. However, there are significant differences in their responses.

Chrome: in version 137, released on 26 May 2025, introduced measures to block the exploited ports and disable certain SDP Munging formats used by Meta Pixel. These defences are said to block the Meta and Yandex localhost communication formats currently in use.
- Assessment: it must be said that Chrome’s measures are limited, with the fundamental problem that Google itself is a “suspect”, as it is a huge advertising platform and the collection of user data is central to its business model. In a situation of conflict of interest, it is difficult to expect drastic measures to be taken that truly put user privacy first.
Firefox: blocks ICE credentials through SDP Munging, and UDP communications are planned to be blocked in future versions.
- Assessment: currently limited, but promising; Mozilla, the developer of Firefox, is led by a non-profit organisation and has a strong commitment to protecting user privacy. Its track record, including measures to track past browsing history, is commendable. Expectations are high for further privacy enhancement measures in the future.
DuckDuckGo: the block list has been modified to minimise the impact of this issue.
- Assessment: DuckDuckGo’s behaviour is too limited. The measures taken by the blocklist are a “tease” to block known patterns after the problem is discovered, and do not go as far as the fundamental measures taken by Brave.
Brave: since 2022, it has not been affected by this issue as it requires user consent for localhost communications and also implements blocklists.
- Assessment: as far as we can currently see, Brave’s response is the most comprehensive and useful. It was addressed before the problem arose in the first place.

The “Localhost Access Permission” mechanism put in place by Brave is very good by design.

Advantages of Brave’s local host access permissions

Default access denial:

By default, Brave does not allow any site to access local host resources. This is the most robust security setting, ensuring that this type of communication does not occur unless the user consciously grants permission.

While many browsers have been relatively permissive towards local host communication, this default denial stance is noteworthy.

Clear permission prompts for users:

When a site listed in Brave’s trusted site list attempts to access local host resources for the first time, Brave displays a clear permission prompt to the user.

This allows users to understand what is happening and decide for themselves whether to grant access. This contrasts with Meta Pixel’s ‘silent communication.’

Combination of blocklist and allowlist:

Brave maintains a filter list that blocks scripts and sites reported for abuse.

At the same time, it operates an ‘allow list’ that enables users to grant permission prompts for sites that require localhost access for legitimate reasons. This balances necessary functionality with privacy protection.

Manual settings change option:

Users can manually manage localhost access permissions for individual sites via brave://settings/content/localhostAccess (desktop version) or ‘Settings > Site Settings > Localhost Access’ (Android version).

Why is this comprehensive?

In the case of Meta Pixel, it wasn’t just the abuse of WebRTC that was the problem, but also the silent access to local ports itself. Brave’s countermeasure takes a more fundamental approach, requiring explicit user permission for any sub-requests to the local host, rather than targeting specific protocols (such as WebRTC SDP Munging).

This means it provides a certain level of defence against new local host abuse techniques that may emerge in the future. While other browsers block specific abuse forms (such as SDP Munging) on a case-by-case basis, Brave’s comprehensive approach is based on its strict rule of ‘local host access is prohibited by default and requires permission.’

Google as the ‘suspect’: The deception of Privacy Sandbox and Topics API

Currently, Google is introducing a new system called Privacy Sandbox and moving towards eliminating traditional third-party cookies. However, there is still room for debate as to whether this is truly a measure to protect user privacy or a strategy to maintain Google’s own advertising revenue.

The issue with the Privacy Sandbox lies in its lack of alignment with Google’s advertising revenue model. While it is presented as a mechanism to enhance privacy, the fact that it retains a structure that allows user behaviour to be leveraged for advertising targeting remains a significant concern.

In particular, after FLoC (Federated Learning of Cohorts) was discontinued, new alternatives such as Topics API and FLEDGE were introduced. However, these mechanisms are also seen as a means for Google to continue collecting data to optimise ad delivery, and there are criticisms that they do not lead to fundamental privacy protection.

When accessing the article titled ‘Osaka Expo Limited Edition “ICOCA” to Expand Sales: 30,000 Additional Synthetic Leather Pass Case Sets’ in Chrome, the following Topics were displayed.

▲An example where topics such as mobile phone repairs and personal loans are assigned to an article about the Osaka Expo. This highlights the issues with the Topics API.

In the case of the ‘Osaka Expo-exclusive “ICOCA”’ topic, assigning topics such as mobile phone repairs, service live video streaming, and personal loans does not make sense. This suggests that the Topics API may not accurately reflect users’ viewing content and could assign inappropriate topics, which is also a concern from a privacy protection perspective.

Limitations of conventional countermeasures by users

While this hidden tracking method was in effect, it worked even if users were not logged into Facebook or Instagram on their mobile browsers, even if they used incognito mode, and even if they cleared their cookies and browsing history.

In other words, traditional privacy protection features (such as clearing cookies, using incognito mode, and Android permission controls) were bypassed by this specific method. Additionally, even if a website loaded the Meta Pixel script before the user agreed to the cookie consent form, this tracking action was triggered.

The Never-Ending Cat-and-Mouse Game: Platform Providers’ Responsibility

The biggest issue is that even after the discovery of Rakuten ad4U, platform operators have continued to develop malicious tactics. As long as they disregard user privacy and persist with sophisticated tracking methods, they will never gain users’ trust. Companies should not only pursue profits but also fulfil their social responsibilities.