



Meta and Yandex Are De-Anonymizing Android Users' Web Browsing Identifiers (github.io) 69
"It appears as though Meta (aka: Facebook's parent company) and Yandex have found a way to sidestep the Android Sandbox," writes Slashdot reader TheWho79. Researchers disclose the novel tracking method in a report: We found that native Android apps -- including Facebook, Instagram, and several Yandex apps including Maps and Browser -- silently listen on fixed local ports for tracking purposes.
These native Android apps receive browsers' metadata, cookies and commands from the Meta Pixel and Yandex Metrica scripts embedded on thousands of web sites. These JavaScripts load on users' mobile browsers and silently connect with native apps running on the same device through localhost sockets. As native apps access programmatically device identifiers like the Android Advertising ID (AAID) or handle user identities as in the case of Meta apps, this method effectively allows these organizations to link mobile browsing sessions and web cookies to user identities, hence de-anonymizing users' visiting sites embedding their scripts.
This web-to-app ID sharing method bypasses typical privacy protections such as clearing cookies, Incognito Mode and Android's permission controls. Worse, it opens the door for potentially malicious apps eavesdropping on users' web activity.
While there are subtle differences in the way Meta and Yandex bridge web and mobile contexts and identifiers, both of them essentially misuse the unvetted access to localhost sockets. The Android OS allows any installed app with the INTERNET permission to open a listening socket on the loopback interface (127.0.0.1). Browsers running on the same device also access this interface without user consent or platform mediation. This allows JavaScript embedded on web pages to communicate with native Android apps and share identifiers and browsing habits, bridging ephemeral web identifiers to long-lived mobile app IDs using standard Web APIs. This technique circumvents privacy protections like Incognito Mode, cookie deletion, and Android's permission model, with Meta Pixel and Yandex Metrica scripts silently communicating with apps across over 6 million websites combined.
Following public disclosure, Meta ceased using this method on June 3, 2025. Browser vendors like Chrome, Brave, Firefox, and DuckDuckGo have implemented or are developing mitigations, but a full resolution may require OS-level changes and stricter enforcement of platform policies to prevent further abuse.
These native Android apps receive browsers' metadata, cookies and commands from the Meta Pixel and Yandex Metrica scripts embedded on thousands of web sites. These JavaScripts load on users' mobile browsers and silently connect with native apps running on the same device through localhost sockets. As native apps access programmatically device identifiers like the Android Advertising ID (AAID) or handle user identities as in the case of Meta apps, this method effectively allows these organizations to link mobile browsing sessions and web cookies to user identities, hence de-anonymizing users' visiting sites embedding their scripts.
This web-to-app ID sharing method bypasses typical privacy protections such as clearing cookies, Incognito Mode and Android's permission controls. Worse, it opens the door for potentially malicious apps eavesdropping on users' web activity.
While there are subtle differences in the way Meta and Yandex bridge web and mobile contexts and identifiers, both of them essentially misuse the unvetted access to localhost sockets. The Android OS allows any installed app with the INTERNET permission to open a listening socket on the loopback interface (127.0.0.1). Browsers running on the same device also access this interface without user consent or platform mediation. This allows JavaScript embedded on web pages to communicate with native Android apps and share identifiers and browsing habits, bridging ephemeral web identifiers to long-lived mobile app IDs using standard Web APIs. This technique circumvents privacy protections like Incognito Mode, cookie deletion, and Android's permission model, with Meta Pixel and Yandex Metrica scripts silently communicating with apps across over 6 million websites combined.
Following public disclosure, Meta ceased using this method on June 3, 2025. Browser vendors like Chrome, Brave, Firefox, and DuckDuckGo have implemented or are developing mitigations, but a full resolution may require OS-level changes and stricter enforcement of platform policies to prevent further abuse.
Class action? (Score:1)
Re:Class action? (Score:4, Insightful)
maybe in EU, they are paid up in US
Big Brother is watching (Score:3)
Re: (Score:3)
Investors. Why do you think they're doing this?
Android Advertising ID (Score:3)
As native apps access programmatically device identifiers like the Android Advertising ID (AAID)
Another reason to routinely change/reset this manually.
(Don't know if deleting it would be better...)
Re: (Score:2)
An app can say "I have ID X and had previously ID Y" and all other apps and websites can add the IDs as aliases for each other in their database.
Changing only disconnects uninstalled apps, as all still installed apps see the same change. They would need to use one Ad-ID per App instead of a global one.
Re: (Score:2)
AFAICT, an easier alternative is to NOT install the apps. Use the website to access those services instead, then there is no local app logged in as you for the webpage to poke.
I'm a bit surprised the browsers allow those localhost connections without any approval. If you look up "javascript based network scanners", they all use really ugly kludges to get around protections that are supposed to prevent such things. I'm pretty sure there should be stuff that ensures a webpage can't scan all locally open ports
Re: (Score:2)
I think the old noscript extension prevented it explicitely. I do not know if the new version does. But with Noscript/uMatrix you can restrict connections even when they may not blacklist localhost by default.
Re: (Score:2)
There used to be a setting in Android to do this automatically on every reboot - I had it set in 2020 for a while - but I failed to find it when looking a couple of weeks ago. The Facebook app is not a problem for me (I placed it in "Forced Stop" on day 1 with my new phone) and Instagram is not installed, but I use WhatsApp. As for Yandox, not on a bet.
Re: (Score:2)
Wouldn't do anything. AAID is like a browser cookie in this case. It's not the primary key for you being tracked, that's Meta's profile on you.
Re: Comment Subject: (Score:2)
Re: (Score:2)
They've found a way to transfer sensitive data from your browser, outside the sandbox, to other apps that do whatever, including steal, it sell it on the black market, or Target you with ads against your will
AFAICT, that goes both directions, and the other direction worries me more.
Go to random webpage.
Said page has nefarious code on it.
That code talks to the local facebook app to get your facebook userid (or some such identifier).
Now that random page knows your facebook identity (and could enumerate over all apps that do such trickery).
Random page can then transmit your secret identity back to their servers or anywhere they like.
IMO, I should be able to open any webpage in a private tab and have an expectation
Prison time? (Score:5, Interesting)
Re: (Score:2)
They haven't touched the person ultimately responsible, Martin Winterkorn, just as they won't touch Zuck.
Re: (Score:2)
Except the question is whether he was ultimately responsible. For that you'd need to prove he know / signed off on this practice. If anything you can accuse him of running a company with a really shitty corporate culture, but to send someone to prison you need to directly and beyond any reasonable doubt prove fraud.
Re: (Score:2)
VW was smart enough not to keep any records of when Winterkorn was informed of the problem and allowed it to continue:
https://www.houstonchronicle.c... [houstonchronicle.com]
https://www.theguardian.com/bu... [theguardian.com]
I also remember reading around the time that the scandal broke that Martin Winterkorn was smart enough to not be too specific when he instructed engineers to find a way to make the cars pass emissions within budget or they'd be fired, and that he didn't care how they did it.
Interesting story, I also heard from an engineer at G
Re: (Score:2)
VW execs went to prison for lying to the government. These assholes aren't even lying to their customers, they're lying to their product.
Re: (Score:2)
The problem is that this isn't fraud. If anything it is programmatically bypassing an API. The question is whether this is a GDPR violation, and chances are someone could prove it's not.
Solution (Score:2)
I use some of these services in a "privacy" window with Ad blockers, etc and delete all cookies afterwards.
Their Apps are in now way equal compensation for my loss of privacy and data harvesting.
Fuck them.
Re: (Score:3)
>"Do not have Apps for Facebook, Amazon, Google, Microsoft, Twitter/X, etc etc etc. I use some of these services in a "privacy" window with Ad blockers, etc and delete all cookies afterwards.""
I will do you one better. I don't even have accounts on any of them, never have, and don't use any social media (unless you count Slashdot and a few forums as "social media" (I don't )). And I survive just fine. I do have an Amazon account, I don't consider that the same thing at all, however.
>"Fuck them."
In
Don't install those apps (Score:4, Interesting)
Now days it comes as no surprise. It also comes as not surprise that most people, especially the younger ones, just don't care and will happy give any company any info they want so they can keep endlessly scrolling through dross.
Re: (Score:2)
If I understand what they are doing right it seems like the easy fix is to not install the related native apps.
I wouldn't count on this. I have noticed that a lots of web sites connect to localhost. I always assumed it had some semi-malicious reason. Even now I notice that slashdot is connecting to 1248321188.rsc.cdn77.org. I'd assume that this is basically the same idea.
Re: (Score:3)
Time for some fucking privacy laws... (Score:3)
But then profit "trumps" rights, so we're back to getting fucked by the oligarchs who actually run the country.
Re: (Score:3)
The US government is not ignorant to privacy issues at all, but actually actually part of the problem, since agencies routinely buy personal information on citizens from private companies; AKA Data brokers; in order to circumvent our constitutional rights.
Privacy laws would thwart their shenanigans, so there are powerful forces that impede progress.
Re: (Score:2)
In the "freest" country on the planet... . But then profit "trumps" rights, so we're back to getting fucked by the oligarchs who actually run the country.
Freedom is now based on a scorecard. That scorecard is essentially net worth. Those with more have more freedom. Those with less have less freedom. If you are high enough on the freedom scale, you're free to do anything you want to those under you on the freedom scale. America, land of the elite, and those who are their subjects and slaves.
Re: (Score:1)
It's even funnier in Russia (Score:5, Informative)
There's a spicy thing that looks like a state-mandated program that's been going on in Russia for a couple of years now, since 2023 or something: it turns out [vc.ru] a bunch of major Russian Android apps -- Sber, VK, Wildberries, even AliExpress Russia -- quietly request the READ_GSERVICES permission. This lets them grab your Google Services Framework ID, a persistent device ID that survives app reinstalls and SIM swaps. Translation: perfect for long-term tracking.
The punchline? The international AliExpress app doesn't need this permission -- only the Russian one does. So either the Russian dev team's just really curious, or someone upstream wants tighter user traceability. ;-) It's like digital surveillance on hard mode: no GPS, no drama -- just one stable ID and a dash of plausible deniability.
Re: (Score:2)
Given how critical that permission is, how are they even able to request it quietly? I would think Android would be screaming at the top of its lungs if that permission were requested.
Workaround (Score:2)
Re:Workaround (Score:4, Interesting)
The problem would be best fixed by preventing scripts in a browser from being able to connect to random ports on localhost that they shouldn't have been able to do in the first place. Why is it the case that they can, anyways?
I'm pretty sure Chrome on a PC doesn't have the same opening. Websites are generally bound by the same origin policy. A script should only be able to connect to resources at the same hostname as the website; for example connecting a websocket to a port on 127.0.0.1 should only be allowed if the website was actually hosted on 127.0.0.1. Navigating the local browser to http://localhost/ [localhost] URLs at non-standard port numbers by script should also be blocked, and an Android phone ought not to be allowing random apps to bind to port 80 if that were the case.
Re: (Score:2)
Re: (Score:3)
- it can respond with a CORS header which allows sites to read the response.
CORS headers are a recent innovation, And the addition of any headers that can allow a server to make the client relax restrictions may be an extremely bad idea. At least at a fundamental level CORS headers that permit any localhost URL or URL referring to local LAN IP addresses (except for the IP address that script is hosted on) should be blocked by the browser. I believe this is always the case on Desktop browsers.. a ma
Re: (Score:2)
"Why is it the case that they can, anyways?"
Have some app that opens a port and try to connect to it with the browser. You can use stuff that uses web interfaces on mobile devices.
Re: (Score:2)
Have some app that opens a port and try to connect to it with the browser.
That's not a valid reason for the browser to enable a page on "facebook.com" to connect to 127.0.0.1.
In theory that could be a rare reason to allow localhost traffic If the whole browser window is navigated to a page served from 127.0.0.1. But as far as I know Apps don't need to run a own web server to accomplish a local UI, and the Android OS provides such facilities to allow an app to show a HTML page in the browser.
Re: (Score:2)
I'm pretty sure Chrome on a PC doesn't have the same opening. Websites are generally bound by the same origin policy
This policy is site controlled, defaults do nothing to prevent collusion.
Re: (Score:2)
"Blocks websites from using javascript to port scan your computer/network and dynamically blocks all LexisNexis endpoints from running their invasive data collection scripts. "
Re: (Score:3)
I would say that's a different issue. Websites can "scan" the local network by script-creating IMG tags that reference local IP addresses. Even though a script cannot "connect" to random local addresses; it can send a Tag that directs loading an image from a local resource, And then the script can time how long it takes loading to fail in order to test between the conditions whether the port is closed or doesn't exist, and condition where the port is open - which affect how much time it takes t
Re: (Score:2)
Re: (Score:2)
Facebook can easily bundle a TLS-Key with their app. A certificate also works on localhost. There is no requirement that a HTTPS server must be reachable from outside.
Ban them (Score:1)
Like Fixing a Dog (Score:2)
Avoid advertising (Score:2)
I avoided advertising in general: Because it's an explicit hole in the device's isolation from malicious devices. If a developer wants money he can sell his software. Hell, for $5, he can issue a new product every year and demand another $5. That's much cheaper than modern in-the-cloud products demanding $20/month.
Re: (Score:2)
Do you really think that paying for software keeps them from doing this?
Re: (Score:2)
I'm not tolerating advertizing in paid applets, either.
I'm saying I'm willing to pay $3-5 dollars every year. I hope (other users will do the same and) that payment-model will incentivize a few developers to move away from adware/spyware funded applets.
Re: (Score:2)
"I'm not tolerating advertizing in paid applets, either."
Use a Firewall app and be surprised what paid apps do. They contact the same servers as the app with ads, they only don't show the ads. The tracking is all the same for most of them.
Exceeding Authorized Access is a crime (Score:4, Interesting)
Re:Exceeding Authorized Access is a crime (Score:5, Insightful)
There was no way for a cellphone owner to authorize this,
Did you read the terms and conditions carefully before clicking "OK"?
Firefox plugins to avoid this? (Score:4, Interesting)
Would a plugin that blocks tracking pixels fix the problem? I use firefox for android with Ublock Origin installed when I browse on the phone. I do use the facebook app when I access it on the phone, as they have made the mobile browser experience fairly terrible in comparison (on purpose.)
Re: Firefox plugins to avoid this? (Score:1)
No, this is not really fixable at user level unless you uninstall all meta yanfex apps including meta app that shows up only under 'system apps' even if u dont have Facebook whatsapp installed
Meta has already stopped it as per the article. Maybe replaced with something worse.
Don't worry social media will all implode on its own, like every new tech that starts overdoing stuff, in a few years. Bigger problems IRL will take up all your focus n efforts, if that's any comfort
Re: (Score:2)
Re: (Score:2)
Browsers should not allow websites loaded from the WAN to make connections to LAN or localhost addresses without permission.
Re: (Score:2)
uMatrix and not whitelisting 127.0.0.1 can probably help. Firewall-Apps that allow to filter IPs may also help. If you have iptables access you can also drop packets that are going to the port of the listening app. It could be worth a try to start another app that listens on that port before starting the Facebook app.
I need a local compile (Score:2)
Thanks for sharing (Score:3)
I have updated my page on the shittiness of Meta [skoll.ca] with this new information.
Re: Thanks for sharing (Score:2)
Thank you for that.
It'll be patched (Score:2)
Least Privilege Principle (Score:2)
Re: (Score:1)
"There is no reason for any application to become an unrestricted web server for the local browser or any other app."
There are many applications that use web-interfaces as primary interface that you can install on Android.
Is this what the EU wants Apple to do? (Score:1)