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

221–230 of 356 posts

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

#221

Post by SchemaLoad »

microtonal wrote: post #151
bnpxft wrote: post #117

Another reason not to install big tech's apps and only use their websites if you must. Not only our their websites painful which discourages use, websites are more sandboxed.

I am not sure which Meta apps open ports, but e.g. Samsung phones come with a bunch of Meta apps pre-shipped. IIRC just removing the Facebook app is is not enough, there is another service installed that is not visible as an app (com.facebook.services etc.), which you can only uninstall from the data partition with something like ADB/UAD. Or buy an iPhone or a Pixel.

Samsung devices are loaded with malware and AI slop in general. I'd avoid them if you at all care about privacy. Since Google is still missing end to end encryption for cloud data, iOS seems like the only good choice currently.

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

#222

Post by SchemaLoad »

like_any_other wrote: post #64
kriro wrote: post #44

The EU should set some record breaking fines for this. Maybe it's time to invent a tax that starts at 0% and goes up 1-X% every time your hand is cought in the cookie jar. And add a corresponding website where you can clearly see all violations by company.

There should also be fines, but individuals have gone to jail for less.

I agree they should. But I don't think the EU has any real ability to send American tech execs to jail. At most they can stop them doing business in the EU.

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

#224

Post by nuker »

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…

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

I happened to be immune, I disabled Background App Refresh in iOS settings. All app notifications still work, except WhatsApp :(

https://forums.macrumors.com/threads/any-reason-to-use-backg...

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

#225

Post by grg994 »

bakkoting wrote: post #178
JimDabell wrote: post #66

Earlier quoted context omitted.

There is a specification for blocking this: https://wicg.github.io/private-network-access/ It gained support from WebKit: https://github.com/WebKit/standards-positions/issues/163 …and Mozilla: https://github.com/mozilla/standards-positions/issues/143 …and it was trialled in Blink: https://developer.chrome.com/blog/private-network-access-upd... Unfortunately, it’s now on hold due to compatibility problems: https://dev…

Both Firefox [0] and Chrome [1] are working on successors which rely on permissions prompts instead of preflight requests. [0] https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8o... [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8L...

The Firefox bug referenced in [0] is open since 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1481298)?!

What is so difficult about this?

0. Define 2 blocklists: one for local domains and one for local IP addresses

1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default.

2. Add 2 checks in networking stack:

2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches.

2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches.

3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for.

This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?!

And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.

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

#226

Post by mindslight »

charcircuit wrote: post #218
mindslight wrote: post #139

Earlier quoted context omitted.

Browser functionality needs a hard segmentation into disparate categories like "pages" and "apps". For example, Pages that you're merely intending to view don't need WebRTC (or really any sort of network access beyond the originating site, and even this is questionable). And you'd only give something App functionality if it was from a trustable source and the intent was to use it as general software. This would go a…

If it's more profitable for a page to be an app why would people make pages?

It's only "profitable" if people don't bounce at being asked to trust a random news article, or something-embarassing.com, with their personal information. Same as why native Android apps don't just ask for every single permission. People in general do care about their security, they just lack tools to effectively protect it.

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

#227

Post by pests »

microtonal wrote: post #151
bnpxft wrote: post #117

Another reason not to install big tech's apps and only use their websites if you must. Not only our their websites painful which discourages use, websites are more sandboxed.

I am not sure which Meta apps open ports, but e.g. Samsung phones come with a bunch of Meta apps pre-shipped. IIRC just removing the Facebook app is is not enough, there is another service installed that is not visible as an app (com.facebook.services etc.), which you can only uninstall from the data partition with something like ADB/UAD. Or buy an iPhone or a Pixel.

Article did mention Facebook and Instagram at some versions.

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

#228

Post by noduerme »

gruez wrote: post #71
codedokode wrote: post #54

Earlier quoted context omitted.

The website wants to connect to another computer|another app on your computer. Most users probably will click "No" and this is a good choice.

>The website wants to connect to another computer|another app on your computer. "website wants to connect to another computer" basically describes all websites. Do you really expect the average user to understand the difference? The exploit is also non-trivial either. SDP and TURN aren't privacy risks in and of themselves. They only pose risks when the server is set to localhost and with a cooperating app.

Pardon my ignorance, but modern browsers won't even load assets or iframes over plain http within an SSL page. So under normal circumstances you cannot open so much as an iframe to "localhost" from an https url unless you've configured https locally. Regardless of crossdomain perms. Wouldn't you want to require a special security permission from an app that was trying to setup a local server, AND require confirmation from a browser that was trying to connect to a local server?

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

#229

Post by SquareWheel »

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…

This is very misleading. Google was prevented from disabling third-party cookies due to intervention by the CMA, who felt it would provide an unfair advantage over other advertisers. Google argued their case for years, proposed competing standards to act as a replacement (see Topics API), and eventually gave up on the endeavour altogether and simply made it a user toggle.
Post reply on HN