Live data from Hacker News

Covert web-to-app tracking via localhost on Android

localmess.github.io

231–240 of 356 posts

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

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

I remember a few years ago analyzing a modern Samsung phone's web traffic. It had by far the most ad-related and monetizing connections out of any other phone I've ever seen. And they were part of "necessary" functions, so you couldn't just block that traffic.

Samsung has great tech, but I avoid because it's so bloated and abusive.

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

#233

Earlier quoted context omitted.

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.

Google gets no competitive advantage from removing third party cookies from chrome. The anticompetitive monopolistic tactic was the plan to replace third party cookies with FLoC/Privacy Sandbox/Topics AI, and THAT is what they were not prevented from doing.

No one is trying to stop google from removing third party cookies. Google is just unwilling to remove them without introducing a new anticompetitive tracking tool to replace them.

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

#234

Simple question: would disabling apps from running in the background prevent this? Or, more simply, not staying logged into an app on your phone?

Yes, preventing the app from running in the background (entirely) would prevent it from listening on a port and collaborating with websites via this exploit.

As for the second part: no, logging out of the apps would not necessarily be enough. The apps can still link all the different web sessions together for surveillance purposes, whether or not they are also linked to an account within the app. Meta famously maintains "shadow profiles" of data not (yet) associated with a user of the service. Plus, the apps can trivially remember who was last logged in.

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

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

This is not unique to WebRTC. The same result could be achieved by sending a http request to localhost. The only difference in this case is that using WebRTC doesn't log a http request

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

#236

Does the Yandex HTTPS one mean they're shipping the private key for their cert in the app, therefore anything running on localhost (or on a network with poisoned DNS) can spoof the yandexmetrica site? There is a cert for it in the logs: https://crt.sh/?q=yandexmetrica.com

Yes, but presumably they aren't hosting anything on yandexmetrica.com, so any attackeright as wel register yandexmetrica.net and get an ssl cert for that.

These sites both have the same potential for abuse.

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

#237
post #98

Earlier quoted context omitted.

That feels pretty useless. You might as well do what happens today: enable it by default and allow knowledgable power users to disable it. If it's disabled, show a message to the user explaining why it's needed.

Why not? How is this different than, say, location access, or microphone access? I want to be able to configure this per web site, and a permission prompt is a better interface than having an allow/deny list hidden in settings.

Because users understand what “microphone access” entails. “Use WebRTC?” means nothing to the average user.

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

#238

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

It's impossible and we all know it. Instead, donate or help with the huge adblock lists that are being maintained by a lot of people

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

#239

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

It's impossible and we all know it. Instead, donate or help with the huge adblock lists that are being maintained by a lot of people

A lot of things I would have previously said were impossible have happened in the last half year. If only a few of those things were of the impossibly good type.

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

#240
post #81

Would an individual using this technique to collect information from someone else's computer possibly face prosecution under the Computer Fraud and Abuse act?

This only works if you control the code on both sides (ie. on the website being visited and an app running on the phone). It's not some sort of magic hack that allows you to exfiltrate arbitrary browser history. Therefore it's unclear how it can be construed as "hacking" in any meaningful way. As bad non-consensual tracking done by google/meta/whatever are, it's not covered under CFAA.

I don't know, you're purposefully abusing oversights to completely bypass the sandbox. It's an exploit for sure in my mind, and it seems very intentionally done. Like, it was done this way specifically because it allows them to circumvent other protections they know existed.
Post reply on HN