[smolder]

No, the idea is they're abusing existing APIs for fingerprinting purposes that Firefox privacy settings disallow --canvas font rendering difference detection, detecting your GPU model, and things of that nature.

But this new API demonstrates that Google is not on the consumers side when it comes to limiting tracking/data gathering ability, as the new API is explicitly for fingerprinting.

[afavour]

> No, the idea is they're abusing existing APIs for fingerprinting purposes that Firefox privacy settings disallow

But that’s exactly what I’m saying: the author asserts as fact the reason Chrome worked was because it gives up more personal information but there’s no interrogation of whether that’s actually true and if true, how it’s achieved.

I’m no defender of Google I just believe we should be making arguments we’re able to actually back up.

[CharlieDigital]

Fingerprinting is one of the techniques used to track you across the web.

If the site is serving Google, Meta, or ads from other networks, your unique browser fingerprint is one of the tools that makes it possible to target and retarget you.

[afavour]

I think we’re all aware of that. Where’s the specific evidence that Chrome passed the Cloudflare DDOS protection because it gave up more private information than Firefox did?

[btully]

especially since the author had to change the privacy.resistFingerprinting in Firefox to true to get it to work (meaning that it was able to bypass Cloudflare's loop by being MORE secure). But that appeared to break other non-Cloudflare sites.

I think the fingerprinting is a red herring. Yes, Chrome is less secure. But Chrome worked.

It's quite possible someone at the author's workplace updated their Cloudflare WAF settings and made things more strict, causing more checks. I'd even offer that a Firefox extension might be contributing.

But the argument that Chrome worked because it offered Cloudflare personal information is pretty out there ;)

[dcow]

I thought it was the opposite: that instead of fingerprinting users, web services would instead just ask the browser which topics the user is interested in and display the relevant ADs. It's an explicit design goal to reduce the dependence on fingerprinting users, otherwise why would they do it. Topics are supposed to be the locally sourced privacy preserving alternative to invasive tracking.

Whether Mozilla/Apple/others agree is a different story. The blowback has mostly been around how topics aren't perfect and the design still leaves room for abuse and therefor effectively devolves to traditional tracking: https://mozilla.github.io/ppa-docs/topics.pdf.

[youngtaff]

For me the issue is a browser shouldn’t be making the information on the topics of sites I visit available to anyone who asks

[dcow]

Browsers don’t do that today and the result is that AD networks fingerprint and track you to try and serve you more relevant content.

The argument from supporters is that this is a step away from the “fingerprint and track” status quo MO. The argument from detractors is that it doesn't quite achieve that goal.

All you need to address your concern is for access to the API to be user-configurable.

[account42]

Anyone who believes that ad networks won't continue to do fingerprinting in addition to whatever privacy leaks Chrome adds is a fool.

[dcow]

Not if browsers actually limit access to that data needed to do so.

[youngtaff]

The API to be off by default i.e. it’s opt in and not opt out

And it should be behind a permissions prompt

[soraminazuki]

That's a distinction without a difference. In both cases, user privacy is compromised. If anything, the proposal to make "user agents" snoop on the user is even more infuriating. That sounds more like trojan horse than "user agent."