Live data from Hacker News

Covert web-to-app tracking via localhost on Android

localmess.github.io

121–130 of 356 posts

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

#122
post #72

Earlier quoted context omitted.

>all so that CEOs can afford an extra yacht ...and so consumers can use services/products without having to fork over money. People love the ad-model. Given the option to pay or use the "ad-supported" option, the ad-supported one wins 10 to 1. This means in many cases it doesn't even make sense to have a paid option, because the ad option is just so much more popular. As bad as crypto is, with all the negative things…

I really liked the concept of BAT but the reality left me wanting. Things like "we'll hang on to the tokens of sites that don't use BAT yet for them until they join" gave negative vibes. It all felt a little underbaked. I swing back to Brave once in a blue moon and then remember I've got at least $20's worth of BAT lost forever somewhere.

I'm not a big fan of it or anything, it's just the only crypto I know that was targeting that idea.

I'd love if there was another one that was totally open and just a browser extension away. But I do not think it would ever get off the ground because...

People love the ad model and hate paying for things.

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

#123

Earlier quoted context omitted.

Nothing quite like an instant panicked coverup to confirm guilt and intent. Hopefully not too late to make it into the lawsuit. Assholes.

As someone who works for a similar large org, it's just as likely that some low level programmer put it in without much thought, and then this got surfaces to higher up people who didn't know about it and told them to remove it immediately.

It seems incredibly unlikely a low level programmer could come up with this method then get the necessary code into both the tracking pixel served to third party sites and Meta's android apps without some higher ups knowing about it.

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

#124

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…

> modify Android to hand out a different, temporary IPv6 address to every app

AFAIK this is on the Android roadmap and one of the key reasons they don't want to support DHCPv6. They want each app to have their own IP.

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

#126

A comment I wrote in another HN thread [0] covering this issue: Web apps talking to LAN resources is an attack vector which is surprisingly still left wide open by browsers these days. uBlock Origin has a filter list that prevents this called "Block Outsider Intrusion into LAN" under the "Privacy" filters [1], but it isn't enabled on a fresh install, it has to be opted into explicitly. It also has some built-in exemp…

> There are some semi-legitimate uses, like Discord using it to check if the app is installed by scanning some high-number ports (6463-6472) I would not consider this a legitimate use. Websites have no business knowing what apps you have installed.

I agree, yet at least you can kind of see where they're coming from.

I guess a better example would be the automatic hardware detection Lenovo Support offers [0] by pinging a local app (with some clear confirmation dialogs first). Asus seems to do the same thing.

uBlock Origin has a fair few explicit exceptions made [1] for cases like those (and other reasons) in their filter list to avoid breakages (notably Intel domains, the official Judiciary of Germany [2] (???), `figma.com`, `foldingathome.org`, etc).

0: https://pcsupport.lenovo.com/

1: https://github.com/uBlockOrigin/uAssets/blob/master/filters/...

2: https://github.com/uBlockOrigin/uAssets/issues/23388 and https://www.bundesjustizamt.de/EN/Home/Home_node.html (they're trying to talk to a local identity verification app seems like, yet I find it quite funny)

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

#128

Another similar tracking vector that lets any app detect all installed apps by using android.intent.action.MAIN Query: https://support.google.com/googleplay/android-developer/thre... without the QUERY_ALL_PACKAGES permission. No response from Google. Being used by dozens of apps in the wild. Edit: Original Research link: https://peabee.substack.com/p/everyone-knows-what-apps-you-u... (HN: https://news.ycombinator.com…

Incredible that this was locked.

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

#129

Is there a similar thing on iOS? I always wonder when a random app asks to “find devices on my network”

Possible, but potentially not as practical due to the iOS’ restrictive background process model. There, background tasks are generally expected to quickly do whatever it is they need to and exit and generally can’t run indefinitely. Periodic tasks are scheduled by the OS, with scheduling requests from apps being more likely to be honored if their processes are well-behaved (quick, low resource, don’t crash, and don’t run too frequently) with badly-behaved processes getting run less often.

Apps that keep themselves open by reporting that they’re playing audio might be able to work around this, but it’d still be spotty since users frequently play media which would suspended those backgrounded apps and eventually bump them out of memory.

Post reply on HN