uBlock Origin Integration Investigation

added 14.5 stable All Platforms Task labels

assigned to @ma1

changed the description

added Next label

morgan, thanks very much for creating this ticket. There is no doubt that users of Tor Browser do not like the fact that many (most?) websites ask their browsers to visit dozens of websites just to load a page, many (usually most?) of which are third-party sites of which many (usually most?) are trackers. It is nice to fervently believe that Tor Browser would not share anything of value with those sites, but it is better to simply not send anything to these sites at all. This is why many users of TB install uBlock, uMatrix, uBlockOrigin, or similar tools.

But does uBO actually do what users need it to do? In my experience, it comes preloaded with one or more blocklists, which are hard to control, and there is no obvious way to configure exceptions. It almost seems like a 'take it or leave it' philosophy. This is why I am a uMatrix user. First of all, I can disable ALL third party sites by default, and enable only the ones that are needed to render the site. For a relatively small impact to usability, I can fully avoid the risk that a blocklist creator would have chosen to include false positives or would have chosen to ignore false negatives. At the same time, I can see the blocklist outputs as suggestions, rather like warnings not to enable certain third-party sites without further investigation.

And yes, there is a difference between blocking the execution of scripts (or other content of the sort that is blocked effectively by NoScript) and what uB, uM, and uBO do. The latter allow TB users to not send anything to the remote sites at all. Not even talking to a remote site at all is a stronger form of protection than attempting to manage what you say when you do.

And so, I would say that we must acknowledge that TB users will opt to minimise their traffic to third-party websites. Indeed, it is a choice that must be reconciled with the risk of fingerprinting. But we must be realistic when we consider the effectiveness of anti-fingerprinting measures. Such measures are important, but the best form of privacy is to say nothing at all.

So, I think we can agree that we want to enable something that behaves like one of these tools. Let's think carefully, since we have an opportunity to nudge TB users toward something that we consider safe/effective/friendly/efficient. I would recommend that we ensure that users are in the driver's seat, with a clear recommendation to encourage users to start from a blank slate and create whitelists from there. A curated blocklist (or set of blocklists) could be an alternative, but it is no substitute.

(Is there a way for users to implement an off-by-default, per-site whitelisting policy, preferably with suggestions but not decisions from filter-list providers, in uBO? If so, then how? I do not know about it.)

added Apps::Type::Investigation label

marked this issue as related to #17569

added Apps::Priority::High label

added Apps::Impact::High label

As suggested by @intrigeri, I'm currently in conversation with @anonym to find the sweet spot between the integration work we did for Mullvad and Tails's requirements / rationale / process.

Hopefully we'll come up with something concrete by this week

added Doing label

@anonym on Tails' requirement / rationale / process:

Assumption: users are fingerprintable based on the set of filter lists they have enabled

In Tails we have only looked at which lists to enable from a "what about fingerprinting" perspective, we haven't assessed the usefulness of each list

We enable the default set of lists. presumably most uBlock Origin users use the default lists too, so that is good against fingerprinting.

Uing the same set as Tor Browser would be more important for fingerprinting resistance (since we really want to be as similar as the Tor Browser anonymity set as possible), and the two lists you add for Mullvad Browser seems like nice additions.

The main thing we do is to remove + blacklist (so users cannot get them listed again by clicking "Update now") the regional lists, since that could be used to fingerprint users, using this scripts at build time: https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-includes/usr/share/tails/build/customize-ublock-assets?ref_type=heads

Below I'll list the issue and MR that added the above, but I don't think they add anything useful to the conversation:

AFAICT we don't disable uBlock Origin from refreshing its enabled lists, so I guess it does that in the background at some point. based on the above assumption there's some room for fingerprinting users based on exactly when their lists are refreshed.

So it looks to me that the removing+blacklisting regional lists is the difference that matters

I really think we should review the lists we have added for MB, I'm not entirely sure they are the right approach/choices. Ideally I'd like to talk to the uBO dev or others who has spent more time thinking about these.

As for updating the lists, we also talked about proxying the lists, which could give use control on how often they get updated (potentially even provide an onion service). But this is probably another discussion.

We enable the default set of lists. presumably most uBlock Origin users use the default lists too, so that is good against fingerprinting.

Not good for fingerprinting per se, since we don't care about uBlock Origin users in other browsers, but probably better for web-compat I would bet

@ma1 Are user-added rules per site or are they global?

Are user-added rules per site or are they global?

They can be both, filters syntax is extremely flexible.

Can we feasibly disable global custom rules to mitigate some fingerprinting risk?

AFAICT we don't disable uBlock Origin from refreshing its enabled lists

I'm not sure it works these days, but it seems we do try: https://gitlab.tails.boum.org/tails/tails/-/blob/stable/config/chroot_local-includes/usr/share/tails/uBlock-disable-autoUpdate.diff?ref_type=heads (introduced in https://gitlab.tails.boum.org/tails/tails/-/commit/4327564d97563683d484e348b53555fe54a10cdf)

@morganava wrote:

Can we feasibly disable global custom rules to mitigate some fingerprinting risk?

On top of my head I can't see any way that's easy for us (we should patch the filters as they're saved) and understandable from the UXe perspective (we should explain users what's happening) without intervening on uBO's code.

@intrigeri wrote:

AFAICT we don't disable uBlock Origin from refreshing its enabled lists I'm not sure it works these days, but it seems we do try

That, might be much easier for us if we want to.

uBlock Origin Integration Investigation

Designs

Child items 0

Activity