Live data from Hacker News

Covert web-to-app tracking via localhost on Android

localmess.github.io

341–350 of 356 posts

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

#341

Earlier quoted context omitted.

> probably querying for ... Exactly. You need to infer that, it isn't stated directly. Same like you need to guess, that "Unable to connect" means connection refused, while "We can’t connect to the server at a" means the DNS request failed. Or does it mean no route to host? Network is unreachable? I would argue, that (sometimes) the user would be fine to distinguish whether he wants to approve something, but can't be…

> Exactly. You need to infer that, it isn't stated directly. I don't care. The site is doing something unusual. It's evident, it's enough to take a second look and think about it. > Same like you need to guess, that "Unable to connect" means... Again, as a layman, I don't care. As a sysadmin, I don't worry, because I can look into in three seconds flat. Also, Unable to Connect comes with its reasons in parantheses al…

> I don't care. The site is doing something unusual. It's evident, it's enough to take a second look and think about it.

Is it enough to do an informed decision?

> Again, as a layman, I don't care.

You do care, whether you mistyped or the network is down. I agree that you probably don't care to distinguish between "network unreachable" and "no route to host" though.

> As a sysadmin

True, but that information was already there and was thrown away.

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

#342
post #336

Earlier quoted context omitted.

Depending on the data you collect, targeting by user - unfortunately - works. If the granularity is not one user, it will be a hundred. If not, a thousand, and so on. I've seen apps run ads targeting a total of 5 cohorts(together holding a hundred million users), and I've seen companies run ads targeting 100s of cohorts with the same number of users. They all work better than no targeting at all. However what you're…

Before you target 5 different cohorts it's better to target the context of where the ad is shown. i.e. web content normally already has a category and people reading an article about cheap flats in a city might be very much interested in renting or buying a flat. By collecting signals on a user you might only get that interested after a longer time, if you even have a profile, and by the time you pick it up they migh…

Yes definitely. User level targeting comes after targeting particular ad spaces in some ad platforms. But it still adds enough marginally to be useful.

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

#344

Earlier quoted context omitted.

> Exactly. You need to infer that, it isn't stated directly. I don't care. The site is doing something unusual. It's evident, it's enough to take a second look and think about it. > Same like you need to guess, that "Unable to connect" means... Again, as a layman, I don't care. As a sysadmin, I don't worry, because I can look into in three seconds flat. Also, Unable to Connect comes with its reasons in parantheses al…

> I don't care. The site is doing something unusual. It's evident, it's enough to take a second look and think about it. Is it enough to do an informed decision? > Again, as a layman, I don't care. You do care, whether you mistyped or the network is down. I agree that you probably don't care to distinguish between "network unreachable" and "no route to host" though. > As a sysadmin True, but that information was alre…

> Is it enough to do an informed decision?

With my layman hat, yes it is. I'll think about a trade-off between site's importance in my life, trustworthiness of the body behind the site, and my privacy.

> You do care, whether you mistyped or the network is down.

No I don't. Because it's easy to check for a typo, and then it's easy enough to investigate like layman. e.g.: Try going to Google, check for your (wireless) connection from your taskbar, every OS shows a "!" when internet is unreachable, and so on...

> but that information was already there and was thrown away.

Sometimes starting with a truncated but accurate info allows a way faster start. Precision and accuracy are different things, and accuracy is more important than precision.

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

#345
post #257

Earlier quoted context omitted.

it does exist in `about:config`, which could be made as a UI setting instead: `media.peerconnectin.enabled`. on cromite[1], a hardened chromium fork, there is such a setting, both in the settings page, as well as when you click on the lock icon in the address bar. [1]: https://cromite.org

IIRC the standard mobile firefox version no longer makes about:config available. You need to be on a beta or nightly build to access it.

Why are they CONSISTENTLY make Firefox worse? I really want to love it, and I use it because its basically the only choice but ffs

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

#346

Earlier quoted context omitted.

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.

My Samsung phone has Netflix, Spotify, and some Microsoft stuff installed, but nothing from Meta.

Even the flagship Galaxy S25 (OEM, unlocked) has Facebook services preinstalled.

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

#347

Earlier quoted context omitted.

What about "This website would like to connect to the Instagram App and may share your browsing history and other personal details."

Why should that message show up when I'm trying to make a video call in my browser? I'm just trying to call my nephew.

The nessage only makes sense when the remote ist localhost

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

#348
post #155

Earlier quoted context omitted.

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.

The Pixel "Private Space" feature should prevent Meta apps from running in the background. It also prevents you from getting notifications.

I kinda wonder if pushing it into a separate/work profile would isolate it from this... though it kinda smells to be like something that might accidentally (or "accidentally") leak.

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

#349

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 problem is their greed is unlimited and their power/influence and purchasing power is relative to all of the other billionaires corrupting government and making every little facet of life of ordinary people more expensive, miserable, transactional, and punitive.

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

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

I expose a LAN accessible status board from an app via HTTP. The app runs completely offline, thus I can't rely on something hosted on the public internet. My last electron app did effectively the same thing. I took the hosted version of my app and bundled in electron for offline usage with the bundled app being just a normal web application started by electron.

I'm not sure I get it. Why isn't the status board just part of the app itself - why does it need to be accessed via browser?
Post reply on HN