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

71–80 of 356 posts

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

#71

Post by gruez »

codedokode wrote: post #54
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…

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.

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

#72

Post by rkomorn »

Workaccount2 wrote: post #68
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

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

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

#73

Post by matthberg »

JimDabell wrote: post #66
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…

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…

Yep! Unfortunately its main method (as far as I remember from when I first read the proposal at least, it may do more) is adding preflight requests and headers to opt-in, which works for most cases yet doesn't block behind-the-lines collaborating apps like mentioned in the main article. If there's a listening app (like Meta was caught doing) that's expecting the requests, this doesn't do much to protect you.

EDIT: Looks like it does mention integrating into the permissions system [0], I guess I missed that. Glad they covered that consideration, then!

0: https://wicg.github.io/private-network-access/#integration-p...

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

#74

Post by bravesoul2 »

matthberg wrote: post #56
pabs3 wrote: post #10

I'm surprised browsers don't isolate each of the localhost/localnet/internet networks from each other. Are there any use-cases for allowing this?

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.

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

#75

Post by deepsun »

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…

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.

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

#76

Post by paxys »

mig39 wrote: post #69
dylan604 wrote: post #53

Earlier quoted context omitted.

Which begs the question why is this specific to Android? Why would Meta/Yandex not be doing this on iOS, or why did this study not report on iOS?

Doesn't iOS prompt you to give apps permission to connect to your local network? "App would like to find and connect to devices on your local network" or something along those lines. I always hit the "no thanks" button.

In this case it's the web browser connecting to the network, so the permission is irrelevant.

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

#77

Post by gruez »

fluidcruft wrote: post #33
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?

>abusing mandated GDPR cookie notices to secretly track people?

How does that even work? What can GDPR cookie notices can do that the typical tracker can't do?

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

#78

Post by bravesoul2 »

Xiol32 wrote: post #6

Crap like this is why I haven't had the Facebook or Instagram apps installed for years. I still have accounts, but I only visit them via the browser.

It just wants to make me bin my phone tbh. Thank God for RMS and Linus that at least you can run GNU and Linux on a laptop as there is little left outside the panopticon.

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

#79

Post by JimDabell »

paxys wrote: post #52

All apps + the web browser being able to communicate freely over a shared localhost interface is such a glaring security hole that I'm surprised both iOS and Android allow it. What even is a legitimate use case for an app starting a local web server?

> What even is a legitimate use case for an app starting a local web server?

There are apps on iOS that act as shared drives that you can attach via WebDAV. This requires listening on a port for inbound WebDAV (HTTP) requests.

Post reply on HN