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

331–340 of 356 posts

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

#331

Post by SquareWheel »

turtletontine wrote: post #311
SquareWheel wrote: post #244

Earlier quoted context omitted.

> No one is trying to stop google from removing third party cookies. That's simply not true. As I already mentioned, the CMA presented a legal challenge which you can read about online. Please review the history, as it's been going on for years now. https://www.gov.uk/government/news/cma-to-have-key-oversight... https://www.marketing-beat.co.uk/2024/02/06/cma-cookies-goog...

The first link confirms exactly what I said above. They’re not preventing Google from removing third party cookies, they’re preventing Google from implementing ALTERNATIVES to third party cookies. The only reason Google is unwilling to straight up remove third party cookies is their business model. The CMA was concerned that, without regulatory oversight and scrutiny, Google’s alternatives could be developed and impl…

It is true that the CMA is concerned with the new API proposals within the Privacy Sandbox such as Topics. However, this is from an anti-competitive angle, rather than privacy. Their goal is to ensure market fairness.

As part of that same process, they have put considerable friction in place for removing third-party cookies. They've deemed that the removal of third-party cookies could give Google an unfair market advantage, and that is why they're concerned with finding an alternative solution to replace them. This has been a very slow process, and involves many discussions and debates with regulators. That has had significant influence on the design of the Topics API.

To provide a more direct example, the CMA have also put specific stalls into the deprecation process, such as the standstill period invoked last year:

> The CMA will start a formal review of Google’s plan to deprecate cookies and Chrome’s Privacy Sandbox replacements once Google triggers a 60-day standstill period, likely at the beginning of the third quarter. During this standstill, the tech giant is forbidden to put in motion any deprecation procedures on Chrome. ... If they can’t reach an agreement, the 60-day standstill period will become 120 days.

https://www.adweek.com/programmatic/the-cma-is-prepared-to-d...

To put it simply, third-party cookies would have been dead and buried long ago if this dispute were not happening. It may be possible for Google to remove third-party cookies without a replacement, but they'd have be risking a significant lawsuit and contravention of UK authority by doing so.

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

#332

Post by 1718627440 »

bayindirh wrote: post #302
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…

When enrolling Yubikeys and similar devices, Firefox sometimes warns "This website requires extra information about your security device which might affect your privacy. Do you want to give this information? Refusing might cause the process to fail." You can use a similar language for WebRTC.

I wouldn't understand that. Is it getting a manufacturer address to block some devices? Does it use a key to encrypt something? Which "security device? /dev/urandom?

I see that non-technical users can be confused by too much information, but when you omit this even knowledgeable users can't make an informed decision.

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

#333

Post by lynx97 »

throwanem wrote: post #313
gbalduzzi wrote: post #288

Earlier quoted context omitted.

> Targeting by user doesn't work anyway. How did you reach this conclusion? The main problem is that it works way better than traditional marketing medium. It's the reason Google and Facebook are so massive, why would publishers choose to pay them if it doesn't work?

By the same logic cigarettes are presumptively beneficial...

https://www.youtube.com/watch?v=ESoYS9SZW-4

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

#334

Post by akimbostrawman »

worik wrote: post #187

This is yet another reason for installing very few apps

The issue isn't the amount of apps but that they are from big tech store and closed source which for 99% of apps means they will spy for profit.

You can install all of f-droid.org apps and not a single one will do that.

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

#335

Post by nedt »

gbalduzzi wrote: post #288
nedt wrote: post #287

Earlier quoted context omitted.

It's already enough to just have plain ads. Like we have them on the streets, at the bus station, newspapers, etc. No tracking needed at all, just give out the message. If you need to target people to it in the context of the place or content you are showing it with. But you don't need to know anything about the user seeing the ad. Targeting by user doesn't work anyway.

> Targeting by user doesn't work anyway. How did you reach this conclusion? The main problem is that it works way better than traditional marketing medium. It's the reason Google and Facebook are so massive, why would publishers choose to pay them if it doesn't work?

I've seen it being used.

Like on the frontend side with Facebook which thinks if I'm interested into cycling I will also be interested in cars (both are on the street, right?) or if I'm interested in some more dirty humor I also want to see more "naughty" stuff.

And also on the backend used by magazines and they mostly don't use the user profiles because it's too targeted and doesn't have enough audience. And if you make the targeting broad enough you'll have again people interested in chocolate so you target them with wine and whiskey.

Or even better on Amazon where you can buy a new TV and when you have done so it will suggest you even more TVs for the next months.

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

#336

Post by nedt »

porridgeraisin wrote: post #316
nedt wrote: post #287

Earlier quoted context omitted.

It's already enough to just have plain ads. Like we have them on the streets, at the bus station, newspapers, etc. No tracking needed at all, just give out the message. If you need to target people to it in the context of the place or content you are showing it with. But you don't need to know anything about the user seeing the ad. Targeting by user doesn't work anyway.

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 might have a new flat and are no longer interested.

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

#337

Post by bayindirh »

1718627440 wrote: post #332
bayindirh wrote: post #302

Earlier quoted context omitted.

When enrolling Yubikeys and similar devices, Firefox sometimes warns "This website requires extra information about your security device which might affect your privacy. Do you want to give this information? Refusing might cause the process to fail." You can use a similar language for WebRTC.

I wouldn't understand that. Is it getting a manufacturer address to block some devices? Does it use a key to encrypt something? Which "security device? /dev/urandom? I see that non-technical users can be confused by too much information, but when you omit this even knowledgeable users can't make an informed decision.

You would because there'll be context:

1- You'd be in a page where you'll be enrolling your YubiKey or WebAuthn device. You'll be having your key at hand, or recently plugged in.

2- Your device's LED would be flashing, and you'll be pressing to the button on your device.

3- The warning will pop-up at that moment, asking that question to you. This means the website probably querying for something like the serial number of your key, which increases the security, but reduces your privacy.

With the context at hand, you'd understand that instantly, because the place you are and the thing you're doing perfectly completes the picture, and you're in control of every step during the procedure.

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

#338

Post by 1718627440 »

bayindirh wrote: post #337
1718627440 wrote: post #332

Earlier quoted context omitted.

I wouldn't understand that. Is it getting a manufacturer address to block some devices? Does it use a key to encrypt something? Which "security device? /dev/urandom? I see that non-technical users can be confused by too much information, but when you omit this even knowledgeable users can't make an informed decision.

You would because there'll be context: 1- You'd be in a page where you'll be enrolling your YubiKey or WebAuthn device. You'll be having your key at hand, or recently plugged in. 2- Your device's LED would be flashing, and you'll be pressing to the button on your device. 3- The warning will pop-up at that moment, asking that question to you. This means the website probably querying for something like the serial numbe…

> 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 because both dialogs state the same wishy-washy message. Even non-technical users (might) eventually learn the proper terms, but they can't if they only get shown meaningless statements.

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

#339

Post by bayindirh »

1718627440 wrote: post #338
bayindirh wrote: post #337

Earlier quoted context omitted.

You would because there'll be context: 1- You'd be in a page where you'll be enrolling your YubiKey or WebAuthn device. You'll be having your key at hand, or recently plugged in. 2- Your device's LED would be flashing, and you'll be pressing to the button on your device. 3- The warning will pop-up at that moment, asking that question to you. This means the website probably querying for something like the serial numbe…

> 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 all the time.

We should think in simple terms.

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

#340

Post by klabb3 »

salawat wrote: post #206
account42 wrote: post #99

Earlier quoted context omitted.

TFA list tens of thousands of websites using WebRTC for deanonymization. How many websites using it for P2P data transfer can you list?

Any Jitsi deployment? Let's be clear here. Meta/other sites are abusing the technology TURN/WebRTC for a purpose it was never intended for, way beyond the comfortable confines of innocent hackery, and we all know it. That's asshole behavior, and worth naming, shaming, and ostracizing over.

> That's asshole behavior, and worth naming, shaming, and ostracizing over.

These exploits are being developed, distributed and orchestrated by Meta. The ”millions of websites” are just hummus recipe content farms using their ad SDKs, and are downstream Zuck in every meaningful interpretation of the term.

Meta has been named and shamed for decades. Shame only works in a society where bad actors are punished by the masses of people that constitute Meta’s products. Doesn’t mean we should stop, only that it’s not enough.

Post reply on HN