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

131–140 of 356 posts

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

#131

Post by xrisk »

matthberg wrote: post #43

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…

Your DNS server not resolving to localhost may also serve as an additional line of defense.

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

#132

Post by btown »

deepsun wrote: post #75
afavour wrote: post #45

Earlier quoted context omitted.

The main application for WebRTC is peer to peer data transfer. I think you can make the argument that it should be behind a permission prompt these days but it's difficult. What would the permission prompt actually say, in easy to understand layman's terms? "This web site would like to transfer data from your computer to another computer in a way that could potentially identify you"? How many users are going to be ab…

Let it show "Use WebRTC?". If users don't understand, they click whatever. If the website really needs it to operate, it will explain why before requesting, just like apps do now. Always aim for a little more knowledgeable users than you think they are.

And specifically, if you're on something-sensitive.com in a private browsing session, it would give you the choice of giving no optional permissions. That choice is better than no choice at all, especially in a world where Meta can be subpoenaed for this tracking data by actors who may be acting unconstitutionally without sufficient oversight.

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

#133

Post by kube-system »

robin_reala wrote: post #90

Can you imagine the mental hoops you’d need to jump through as a developer to persuade yourself that this is a valid thing to implement?

Zero. People who work on ad-tech build ad-tech all day long, that's the entire job.

Seriously, why do you think all of the unquestionable things humanity has built have been built? It's because it's all just part of the job, for somebody.

People working at ad-tech question the things they're building just like the people at McDonalds flipping a burger are questioning the cholesterol levels of their customers. They're not.

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

#135

Post by maeil »

paxys wrote: post #41
qwertox wrote: post #7

"UPDATE: As of June 3rd 7:45 CEST, Meta/Facebook Pixel script is no longer sending any packets or requests to localhost. The code responsible for sending the _fbp cookie has been almost completely removed." I'm surprised they're allowed to listen on UDP ports, IIRC this requires special permissions? > The Meta (Facebook) Pixel JavaScript, when loaded in an Android mobile web browser, transmits the first-party _fbp co…

These companies have demonstrated repeatedly that fines are just the cost of doing business. Doesn't matter if you charge them $1 million or $1 billion. They have still made significantly more than that from the crime.

That's.. quite the contradictory sentence.

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

#136

Post by btown »

lxgr wrote: post #111
bravesoul2 wrote: post #82

Can this cross profiles? That would be a big security issue for corps. Quick test and if I serve on 8080 on the Userland app it can be accessed from both profiles. So probably yes. This means an infected app on your personal profile could exchange data with a site visited from a second profile.

Only if that site specifically communicates with an (unauthenticated) service bound to a local port though, right?

Which, per the OP, the site would be doing by merely including the Meta pixel, which practically every e-commerce and news site does to track its campaigns and organic traffic.

The takeaway is that for all intents and purposes, anything you did in a private session or secondary profile on an Android device with any Meta app installed, was fully connected to your identity in that app for an unknown amount of time. And even with the tracking code deactivated, cookies may still persist on those secondary profiles that still allow for linking future activity.

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

#137

Post by Orphis »

bravesoul2 wrote: post #74
matthberg wrote: post #56

Earlier quoted context omitted.

If I recall correctly Figma uses it to connect to the locally installed app, and Discord definitely uses it to check if its desktop app is installed by scanning ports (6463-6472). I'm aware of two blockers for LAN intrusions from public internet domains, uBlock Origin has a filter list called "Block Outsider Intrusion into LAN" [0] under the "Privacy" filters, and there's a cool Firefox extension called Port Authorit…

There are surely other ways to achieve this. If you are logged into an app and the site at tbe same time they can use the server to communicate. Discord doesn't need to know if the app is installed to work. That sounds sketchy.

It's just a way to ensure you open the desired context on a local Discord instance, not any instance that might be logged in to your account. I have a few personal computers logged in on Discord on the same account that could be active at the same time for example.

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

#138

Post by lxgr »

btown wrote: post #136
lxgr wrote: post #111

Earlier quoted context omitted.

Only if that site specifically communicates with an (unauthenticated) service bound to a local port though, right?

Which, per the OP, the site would be doing by merely including the Meta pixel, which practically every e-commerce and news site does to track its campaigns and organic traffic. The takeaway is that for all intents and purposes, anything you did in a private session or secondary profile on an Android device with any Meta app installed, was fully connected to your identity in that app for an unknown amount of time. And…

Yes, but if the concern is not mixing business and personal compartment of the phone, business sites would hopefully not embed a Meta tracking pixel.

> The takeaway is that for all intents and purposes, anything you did in a private session or secondary profile on an Android device with any Meta app installed, was fully connected to your identity

Definitely, and that's a huge problem. I just don't think Android business profiles are a particular concern here; leaking app state to random websites in any profile is the problem.

Or do Android "business profiles" also include browser sessions? Then this would be indeed a cross-compartment leak. I'm not too familiar with Android's compartment model; iOS unfortunately doesn't offer sandboxing between environments that way.

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

#139

Post by mindslight »

afavour wrote: post #45
codedokode wrote: post #34

Earlier quoted context omitted.

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.

The main application for WebRTC is peer to peer data transfer. I think you can make the argument that it should be behind a permission prompt these days but it's difficult. What would the permission prompt actually say, in easy to understand layman's terms? "This web site would like to transfer data from your computer to another computer in a way that could potentially identify you"? How many users are going to be ab…

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 long way to solving the other fingerprinting security vulnerabilities, because Pages don't need to be using functionality like Canvas, USB, etc.
Post reply on HN