Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Covert web-to-app tracking via localhost on Android

localmess.github.io

Post reply on HN
Print view View original

31–40 of 356 posts

Re: Covert web-to-app tracking via localhost on Android

#31

Post by merek »

This is the overall process used by Meta as I understand it, taken from https://localmess.github.io/:

1. User logged into FB or IG app. The app runs in background, and listens for incoming traffic on specific ports.

2. User visits website on the phone's browser, say something-embarassing.com, which happens to have a Meta Pixel embedded. From the article, Meta Pixel is embedded on over 5.8 million websites. Even in In-Cognito mode, they will still get tracked.

3. Website might ask for user's consent depending on location. The article doesn't elaborate, presumably this is the cookie banner that many people automatically accept to get on with their browsing?

4. > The Meta Pixel script sends the _fbp cookie (containing browsing info) to the native Instagram or Facebook app via WebRTC (STUN) SDP Munging.

You won't see this in your browser's dev tools.

5. Through the logged-in app, Meta can now associate the "anonymous" browser activity with the logged-in user. The app relays _fbp info and user id info to Meta's servers.

Also noteworthy:

> 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.

> On or around May 17th, Meta Pixel added a new method to their script that sends the _fbp cookie using WebRTC TURN instead of STUN. The new TURN method avoids SDP Munging, which Chrome developers publicly announced to disable following our disclosure. As of June 2, 2025, we have not observed the Facebook or Instagram applications actively listening on these new ports.

Re: Covert web-to-app tracking via localhost on Android

#33

Post by fluidcruft »

merek wrote: post #31

This is the overall process used by Meta as I understand it, taken from https://localmess.github.io/ : 1. User logged into FB or IG app. The app runs in background, and listens for incoming traffic on specific ports. 2. User visits website on the phone's browser, say something-embarassing.com, which happens to have a Meta Pixel embedded. From the article, Meta Pixel is embedded on over 5.8 million websites. Even in I…

Not totally following but it sounds like you are saying one of the things they have been doing involves abusing mandated GDPR cookie notices to secretly track people?

Re: Covert web-to-app tracking via localhost on Android

#34

Post by codedokode »

merek wrote: post #31

This is the overall process used by Meta as I understand it, taken from https://localmess.github.io/ : 1. User logged into FB or IG app. The app runs in background, and listens for incoming traffic on specific ports. 2. User visits website on the phone's browser, say something-embarassing.com, which happens to have a Meta Pixel embedded. From the article, Meta Pixel is embedded on over 5.8 million websites. Even in I…

So main application for WebRTC is de-anonymisation of users (for example getting their local IP address). Why it is not hidden behind permission I don't understand.

Re: Covert web-to-app tracking via localhost on Android

#38

Post by kstrauser »

Agentus wrote: post #35
bix6 wrote: post #22

What happened to all the hackers fighting for personal freedom and privacy? Meta paycheck too tasty?

at some point yah reach a cross road. either sellout and join big brother or join the wandering homeless hordes on the streets.

Eh. You can have a very comfortable career doing work that still lets you look at yourself in the mirror. You don’t have to choose to burn the world to pay the rent.

Re: Covert web-to-app tracking via localhost on Android

#39

Post by IggleSniggle »

pseudocomposer wrote: post #26
voidUpdate wrote: post #4

I wish we could just ban advertising and tracking on the internet. I feel like so much crap these days has come out of it, all so that CEOs can afford an extra yacht

The deprecation of third-party cookies, that all browsers were at one point on track to implement , was pretty much the most realistic first step to that. Which is why Google killed it last year by leveraging their control over Chrome. While not technically a crime, it was a disgusting, unethical market manipulation move that never really got the public outrage it deserved. Google execs’ initial support for it was al…

I don't think that's quite what happened. Google got in anti-trust trouble because they have an unfair advantage in user-tracking, given logged in Chrome accounts. Removing third-party cookies hurts other privacy-invading companies without substantially affecting Google. It was still somewhat on track to be removed from Chrome until they lost their antitrust battle, and Chrome was required to be spun off. With Chrome's new future, and Google's new legal constraints, there's less incentive to try and make Privacy Sandbox work. At least, that was my understanding; I didn't follow it all that closely.

Re: Covert web-to-app tracking via localhost on Android

#40

Post by fc417fc802 »

jeroenhd wrote: post #21

A quite obvious attack mechanism, I'm surprised browsers permitted this in the first place. I can't think of a reason to STUN/TURN to localhost. Aside from localhost, trackers can also use all other IP addresses available to the browser to bind their apps/send traffic to. Now that the mechanism is known (and widely implemented), one could write an app to notify users about attempted tracking. All you need to do is to…

> hand out a different, temporary IPv6 address to every app and segment off any other interface that might be expose

Yes, but (AFAIK) not out of the box (unless one of the security focused ROMs already supports this). The kernel supports network namespaces and there's plenty of documentation available explaining how to make use of those. However I don't know if typical android ROMs ship with the necessary tooling.

Approximately, you'd just need to patch the logic where zygote changes the PID to also configure and switch to a network namespace.

Post reply on HN