Hacker News Reader

I don't mean to support or refuse the author's main points or analysis, but you might like to know that the Chrome team is currently working towards shipping the Topics API. I have strong opinions about it but I will try not to editorialize.

My high-level understanding is that they're going to run an ML model over your browsing history (locally on your device) to build a list of "topics" that you care about. Sites you browse can use the Topics API to pull a set of these interests from the browser to show you "relevant" ads. Mozilla has taken a negative position against this standard.

https://privacysandbox.com/proposals/topics/

https://github.com/mozilla/standards-positions/issues/622

How is that relevant to the topic?

You asked:

>> Chrome will happily collect as much private information about me and my browsing history and share them with select parties, as needed

> What information does Chrome provide in this scenario that Firefox doesn’t?

Key words: "in this scenario"

Is Cloudflare using an as yet unshipped API as part of DDOS protection?

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.

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.

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

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.

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

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

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

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."

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

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.

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?

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 ;)

When I started having this problem logging into a certain credit card co.'s website beginning with about Firefox 105.0.2 on Fedora 38, I was told by their apparently outsourced customer service that I had to use Chrome, which I don't have installed there and couldn't try. Yeah, they wanted me to use LogMeIn so they could fix the problem, too. Right.

Firefox on Android was still working, though, loathe as I am to put passwords of any significance on my phone. Doesn't directly address your question, which I'd like to know the answer to as well.

Brings me back. My company "upgraded" the time entry system at the beginning of this century.. Issue, our whole dev team was on unix (hpux, Solaris) and used firefox, which didn't work anymore (IE only). They solution to have 3 separate terminals we would "cytrix" into an NT machine to do our time machine on Internet Explorer...

Sigh

PayPal's "secure browser" effectively becomes broken by Firefox's first part isolation. that took some time to figure out.

In terms of being blocked by CloudFront (not cloudflare),I actually got a website to fix their policies by just emailing their tech support and showing that simple user-agent changes bypasses their policy anyhow.

A third browser... like what? Chrome and Firefox are all that exist now, unless you have access to a Mac with Safari.

its time to pull out lynx again.

My "third" browser is GNOME Web, however, I uninstalled it thanks to performance issues. I installed Chrome from Flathub, but with limited permissions, which I only use for cross-browser testing. My main browser is Firefox.

Check out Vivaldi...?

You mean "Chromium with extra steps"? I know it's a fork, but the actual engine is still mostly Chromium.

There are a handful of Webkit based browsers out there, though none that popular except for Safari.

But yes, 3 is all we're left with outside of a few bespoke projects...

Honestly the SerenityOS browser (+ its Linux port, Ladybird) is probably the funniest. I wonder if that passes CloudFlare...

Servo seems to be more viable than Ladybird

I remember back when you could run the Servo app on macOS, it was a doge inside a cog and you could actually browse the internet, there was an address bar and back/forward buttons. But now they've actually removed that sort of stuff and given up on making a standalone browser in Rust, in favor of augmenting Firefox instead. See Firefox Quantum.

Mozilla actually fired the Servo developers to focus solely on Firefox (they still employ Rust developers, just not on Servo). But after some years, other companies picked up development on Servo.

Servo doesn't have a browser but I'd wager that writing a full featured browser for Servo would be much more useful than another Blink browser

I think Servo has already served to bootstrap a bunch of Rust-ecosystem things, and that's why they yeeted it. Though webrender and some other offshoots from Servo are still useful for a lot of projects.

Chromium isn't Chome. Microsoft Edge is popular. And Opera is still used: my teen daughter seems to have bonded with it on her own.

Edge is now Chromium and Opera is also Chromium, but touché that I said "Chrome" in my original comment.

I've had sporadic issues with Firefox not working on work-related sites one day when the previous day it worked just fine.

I have ublock, privacy badger, decentraleyes, canvas blocker, facebook disconnect, and duckduckgo privacy essentials installed.

I would go through and disable each extension in order to see if it was the cause of the issue, and so far, every single time it has been duckduckgo privacy essentials that is breaking websites for me.

I think I should remove it at this point, but who knows? Maybe it's protecting me from something that I don't see.

With Firefox you can toggle some settings that will make much harder to generate useful fingerprints. That's already a massive privacy difference.

Why would chrome give that information away? That's Google's most valuable resource.

Maybe they're directly delivering your information for a price. From you to them, directly, via Chrome.

https://privacytests.org/ shows some good data what each browser lets through/exposes for websites.

Caveat: (default settings)

I harden my Firefox installations, and therefore this website comparison isn't useful.

It does have Librewolf and Mullvad listed, which are hardened Firefox forks. But its still not your exact scenario, my bad :)

@afavour: The topic isn't as simple as having a HTTP header with a unique identifier. Browser Fingerprinting is a complex process, that uses unintentional implementation details, like how things are rendered with different graphics drivers or details you can get from APIs that are intended for other purposes (like WebRTC).

The site that morjom posted gives you a simple overview and Firefox is known for the privacy preserving features it comes with. However, you are right, that it is an inexact science as long as we don't know the logic of the Cloudflare implementation.

Chrome will indeed divulge more information than other browsers but only on the condition that you have opted-in for such collection.

“The Chrome User Experience Report (CrUX) provides user experience metrics for how real-world Chrome users experience popular destinations on the web. This data is automatically collected by Chrome from users who have opted in, . . .”

Taken from https://web.dev/crux-and-rum-differences/

It's not a real time API, though. It's an aggregated dataset available via BigQuery. I don't think Cloudflare could use it as part of DDOS protection except in very vague ways.

You're conflating a downside of using Chrome and the reason they think Cloudflare blocked them.

> So I naturally tried to access the same page in Google Chrome to see if I’d still be blocked. Thankfully, I wasn’t.

> But of course I wasn’t because Chrome doesn’t have the same privacy- and security-enhancing designs

Maybe I’m missing something but it seems the conflation was by the article author, not me?

No. And there’s still the central issue of the author really hand-waving the specifics of their accusations about Chrome. It really seems to come down to “Google bad”.

To be clear, I don’t even use Chrome, in part because “Google bad”. This just isn’t intellectually honest.

seems like the author mentioned that in FireFox disabling "privacy.resistFingerprinting" worked. So looks like Chrome by default is allowing the server to collect Fingerprinting. If cloud flare is using that, then it is a big red flag.

Of course they are. Thats the whole point of the 'Integrity Check'. Besides, almost every website you visit collects your fingerprint nowadays.

The opposite. enabling the flag fixed the issue although it broke other sites.

  > Eventually, I found some suggestions that if you’re using Firefox you can disable the privacy.resistFingerprinting option in the about:config page. But that was already listed as false for me when I got stuck, so I switched the value to true just to see if that would do anything.

  > And that worked!