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

211–220 of 356 posts

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

#211

Post by solid_fuel »

nickphx wrote: post #180
lucianbr wrote: post #164

Earlier quoted context omitted.

Unauthorized access to a computer system. I'm sure if I connected to some port on a computer belonging to Meta without them wanting it, that would be the crime I would be charged with. But somehow if Meta connects to a port on my phone without me agreeing to it, it's not a crime?

Yes.. and that listening service is their software that you installed on your device... So caveat emptor.

What function does Instagram provide with this WebRTC listener besides tracking?

People install Instagram to look at photos and reels, not to help facebook track them better.

If I put a crypto-mining script in a game I don't get to claim "well they installed the app" when people complain. The victims thought they were installing a game, not a crypto-miner.

Here, the victims thought they were installing a photo sharing application, not a tracking relay.

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

#212

Post by 0cf8612b2e1e »

crtasm wrote: post #123
IncreasePosts wrote: post #112

Earlier quoted context omitted.

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.

Zuckerberg personally signed off on torrenting books for Llama. It would be a particularly dim group of “low level” programmers who did this without trying to first secure some upper level approvals to share the blame once caught.

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

#213

Post by nickthegreek »

robin_reala wrote: post #141
fanatic2pope wrote: post #114

Earlier quoted context omitted.

My experience is that most developers just do as they are told.

Another reason why AI is so fascinatingly horrible: it’ll never question the moral impact of what you’re trying to do.

except claude was trying to rat out users in their newer trials. in the end, the best whistleblower could end up being the ai… not sure what that says about us though.

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

#214

Post by selcuka »

afavour wrote: post #98
deepsun wrote: post #75

Earlier quoted context omitted.

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.

That feels pretty useless. You might as well do what happens today: enable it by default and allow knowledgable power users to disable it. If it's disabled, show a message to the user explaining why it's needed.

Why not? How is this different than, say, location access, or microphone access?

I want to be able to configure this per web site, and a permission prompt is a better interface than having an allow/deny list hidden in settings.

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

#215

Post by will4274 »

chedabob wrote: post #186

Does the Yandex HTTPS one mean they're shipping the private key for their cert in the app, therefore anything running on localhost (or on a network with poisoned DNS) can spoof the yandexmetrica site? There is a cert for it in the logs: https://crt.sh/?q=yandexmetrica.com

Yup definitely. Edit: the diagram makes it perfectly clear https://yandexmetrica.com:30103/p?...

It even looks like some of the certs were issued by Yandex to Yandex. I guess their cert division will end up writing an incident report for this.

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

#216

Post by SchemaLoad »

cluckindan wrote: post #193
lachlan_gray wrote: post #80

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

It’s probably easier to buy that data directly from Apple. Google’s core business is built on tracking data, so they would be reluctant to sell, necessitating covert collection.

Can you link the page where you can buy that data?

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

#217

Post by pkaeding »

microtonal wrote: post #183
johnisgood wrote: post #168

Earlier quoted context omitted.

I tend to buy stock Android, e.g. Motorola moto g30, etc. It still has lots of Google stuff, but you can get rid of them, and I have a work profile specifically designed for Google-related stuff, and my personal profile is de-Googled as much as possible.

I would recommend everyone who wants a clean Android to look into Google Pixel phones. Aside from being mostly bloat-free (and most bloat can be uninstalled), it is one of the few phones that supports unlocking/relocking and a secure open source alternative (GrapheneOS).

Does grapheneos prevent this? In what way? I know apps like ShareViaHTTP [1] are able to open ports (listening not just on the loopback address). If I installed a meta app, could it still run its listener that scripts on webpages could talk to?

[1]: https://f-droid.org/packages/com.MarcosDiez.shareviahttp

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

#218

Post by charcircuit »

mindslight wrote: post #139
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…

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…

If it's more profitable for a page to be an app why would people make pages?

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

#219

Post by charcircuit »

SecretDreams wrote: post #84
Workaccount2 wrote: post #68

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…

Yes, we need ads for a free internet, today. And, as a result, we also have our privacy eroded - eroded in ways we may not care about today, but will probably regret tomorrow. If we must pay for the internet, give me an option to pay to use it where I see no ads and my privacy is preserved. Let me know what that cost is and I'll decide what I want to do. Right now, the actual pricing is obscured so we just "accept" t…

>give me an option to pay

This will depress ad revenue as the people with the most money will be the people who pay to remove ads. This will make less sites and content viable.

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

#220

Post by 3abiton »

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…

A reminder that it's possible to use tools like XPL-EX to circumvent those attempts. Also ad blocking via adaway would do the trick here I assume, as it should block Meta Pixel tracking. Overall, awful approach.
Post reply on HN