Live data from Hacker News

Covert web-to-app tracking via localhost on Android

localmess.github.io

61–70 of 356 posts

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

#61

To me it's weird that they're willing to misuse browser APIs so blatantly for interprocess communication, when, as I understand it, server-side correlation using a combination of IP, battery level and screen dimensions probably already gets them 95% of the surveillance capability.

Why is this weird to you instead of being "of course they are" to you?

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

#62
post #41
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.

The sum absolutely does matter. All you’re saying is the fines are too low

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

#63

To me it's weird that they're willing to misuse browser APIs so blatantly for interprocess communication, when, as I understand it, server-side correlation using a combination of IP, battery level and screen dimensions probably already gets them 95% of the surveillance capability.

the invisible hand says they have to chase that last 5%, too

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

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

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

#65

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 question is how do you ban it, and then how do you prove that people are breaking those rules?

I think the main problem is lots of money are made from it, and money influences politics hugely. The technical difficulties are low on the list of reasons this is not happening.

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

#66

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://developer.chrome.com/blog/pna-on-hold

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

#67

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…

[deleted]

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

#68

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 attached to it, BAT was probably one of the smartest things to be invented. A browser token that automatically dispenses micropayments to websites you visit. Forget all the details to get snagged on, the basic premise is solid: Pay for what you use. You become the customer, not the advertisers.

Also a note about ad-blocking - it only makes the problem worse. It is not a "stick it to the man" protest. You protest things by boycotting them, or paying their competitors, not by using them without compensating them.

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

#69
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?

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.

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

#70
A commenter mentioned [1] that major Russian apps now all ask for permission to read a unique device ID to deanonymize users. The people that stopped Intel from adding such an ID to their CPUs had perfect foresight [2] (too bad later Intel added it anyway). But then it's not hard to guess that if you include a feature whose purpose is to attack the user, it will be used to attack the user.

[1] https://arstechnica.com/security/2025/06/meta-and-yandex-are...

[2] https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_...

Post reply on HN