pes10k

Its definitely true that you can key responses to request information beyond the URLs, but I think theres more to it than this:

- Lots of tools don't allow you to block requests off those additional keys (Google's Manifest v3 for one, Apple's iOS content blocking too)

- In many cases, making consistent replies based off those keys requires additional information privacy tools also try to limit (referrer fields, cookies, etc)

- There is practical, real world value in making things more difficult for trackers / folks sending you stuff you don't want; decisions are made at the margins!

- Ad blockers are common on the web (estimates 10-30% of users!); they're effective bc they work with the grain of the web, and circumvention is deterred (though not prevented) bc there are costs to circumventing adblockers; WebBundles push those costs to zero. Again, decisions are made at the margins

Again I wrote the piece but…

Folks "who are well actually, you can already make URLs meaningless"'ing are missing the point of how practical web privacy tools work, including the ones you all have installed right now.

There is an enormous, important difference between:

i) circumventions that are possible but are fragile and cost more, and ii) circumventions that are effortless for the attacker / tracker

Every practical privacy / blocking tool leverages that difference now, the proposal collapses it.

Again random urls are just a demonstration of the problem.

At root is private name resolution. What one bundle sees as asdf23f23g.js is different from what another bundle sees as asdf23f23g.js is different from what the web sees as asdf23f23g.js.

A site changing URLs often is a pain filter list authors deal with (automation, etc). Private namespaces for URLs is the real problem here that makes the proposal dangerous (and using it to randomize URLs is just a demonstration of how the dangerous capability can be used)

This is just super wrong. With WebBundles I can call 2 different things, in two different WebBundles https://example.org/good.js, and that can be different from what the wider web sees as https://example.org/good.js.

Random URLs are just an example of the capability they are not the fundamental problem

Will also add that all the other benefits (a single application package is great! signing things is great!) are true! But those do not hang on this aspect of WebBundles

Disclaimer: I wrote the article.

I'm not sure where the claimed confusion is above.

The argument is: I want to include something like fingerprint2.js in my page. I know filter lists block it, bc users don't like it.

W/o web bundles, you have to either inline it (bad for perf), copy it to a new URL (which could later also be added to a list), or add some URL generation logic to the page, and have some server side logic somewhere to know how to understand the programmatically generated URLs.

With WebBundles. I call it https://example.org/1.js (which is a diff than what https://example.org/1.js points to in a different bundle) or even just call it https://example.org/looks-to-be-benign-to-the-web.js.

The claim is not that bundles are coming from random URLs, its that the bundles create private namespaces for URLs, and that breaks any privacy tools that rely on URLs.

Hi, I do privacy research at Brave. Our fingerprinting protections are still being improved (our second round of FP defenses should hit nightly in Jan), but the comments here are wrong; our defenses are much better than Firefox and Chrome.

We don't consider as part of our threat model preventing sites from knowing you're using Brave. I'm not aware of any browser or tool that considers this as part of their privacy threat model either (including the terrific Tor Browser Bundle). Our goal is to prevent sites from distinguishing between Brave users.

My claim is that our fingerprinting protections are strictly stronger than Firefox and Chrome. A partial list of fingerprinting protections that are enabled by default in Brave are at [1].

Fingerprinting is tricky, and we're tacking the problem in on multiple dimensions. We need to go further, and expect to have v2 of our defenses in nightly in the next month or two [2], but we're also leading efforts in W3C to address fingerprinting in standards (I'm snyderp, those are my / Brave issues identifying privacy harm in standards) [3], and we're pushing hard to prevent web standards and privacy efforts from being eaten up by vaporware [4].

So, all that is to say, Brave has the most aggressive fingerprinting protections of any general purpose browser, and is getting better. The naysayers are welcome to backup their claims ;)

1: https://github.com/brave/browser-laptop/wiki/Fingerprinting-...

2: https://github.com/brave/brave-browser/issues/5614

3: https://github.com/w3cping/tracking-issues/issues

4: https://brave.com/brave-fingerprinting-and-privacy-budgets/