Should ublock origin's dynamic blocking mode (medium or hard mode) be recommended over the standard setup?

[Ja-ngolo]

Taking into account this comment made by gorhill and this (https://www.youtube.com/watch?v=2lisQQmWQkY) video made by the hated one. Should the site recommend or have a section explaining how to use Ublock's dynamic blocking? Or is this as you all say just privacy theatre, or are gorhill's claim that this helps against fingerprinting true? As I understand it with dynamic blocking the user is relying less on blocking lists (hence enumerating badness) and more just relying on the extension blocking all 3rd party frames, scripts, and content if desired, and then choosing which connections to allow.

I do recognize that this can be a convoluted approach to going through every page, allowing certain connections and also having the time and knowledge to be able to tell what connections to allow as to not break the sites you are visiting. I would like to also ask you all is this useless if using arkenfox hardening, or at least RFP? Can it be an alternative for people to harden Firefox without having to go the arkenfox route?

(This questions are also general curiosity, and do realize both sources can be outdated since privacy is a cat and mouse game all the time)

[rusty-snake]

YES.

For advanced users (like users who use arkenfox) makes this sense.

As I understand it with dynamic blocking the user is relying less on blocking lists (hence enumerating badness) and more just relying on the extension blocking all 3rd party frames, scripts, and content if desired, and then choosing which connections to allow

Yes, you move to enumerating goodness.

[Ja-ngolo]

ok, but regarding fingerprinting. Does blocking 3rd party stuff works better or similarly to RFP? Does RFP without the arkenfox configurations help against fingerprinting?

[rusty-snake]

Does blocking 3rd party stuff works better or similarly to RFP?

No.

Blocking (with lists or 3p-resources) blocks FP scripts from being executed. RFP minimizes (e.g. spoof device enumeration as as one "Internal Camera" and one "Internal Microphone"), randomizes (Canvas) and reduces timer precision.

Does RFP without the arkenfox configurations help against fingerprinting?

Yes. RFP is 90% of arknfox' FP protection.

[Ja-ngolo]

alright then, thanks for your help!

[Thorin-Oakenpants]

There are many steps to defeating FPing.

The first is blocking of known scripts - e.g. the fastest code or least risk is no code. ETP (and Brave's blocker I believe) by default do this. uBO also does this by default (not that I looked, but for sure these are bound to be in there somewhere). But this is enumerating badness, and while helpful, is not the end game. Also, enumerating badness is easily bypassed - scripts can be (and are) included in 1p files essential for the site to function, and/or given random/different names.

Another step (to help defeat FPing) is to disable APIs, or in uBOs case, you can disable JS - or reduce possible sources (medium/hard whatever). I am not saying that these do not help, but do not think of uBO as a fingerprint solution, that's all I'm saying

The end game is built-in browser solutions - e.g. Brave's shield, FF's RFP. I know, RFP is not for everyone but RFP site exceptions are coming (just like in Brave you can toggle the shield per site). If RFP absolutely sucks for you, you will gain far more by using CanvasBlocker with just canvas and perhaps audio. Once again -> https://github.com/arkenfox/user.js/wiki/3.3-Overrides-[To-RFP-or-Not]#-summary

tl;dr: when finding solutions, you want comprehensive ones - expect the worst. If you are worried about fingerprinting, uBO is not the answer (again, not saying it doesn't help in some small way: or bigger way depending on mode) - also, I love dropping this line in - did you mask your IP?

---

I'll add this here, but it ties in with https://github.com/privacyguides/privacyguides.org/discussions/1712#discussioncomment-3535765

Ignoring fingerprinting - uBO is a content blocker. So it's really up to the end user. Reduce attack surface, reduce requests (perf), reduce eyesores and adverts, etc. I agree with @ph00lt0 that for most people default uBO is all they care about or could handle

anyway, that's my 5cents

[Ja-ngolo]

Yeah I agree with this a lot. Sadly, yeah you caught me i do not mask my IP. But that's more because I do not know what alternatives beyond a vpn there are.

[ghost]

I'd rather link back to the dev's documentation on how to set up the extension rather than recommend any particular setup.

[ph00lt0]

Disagree tbh. I personally can read the dev's documentation but this is for a lot of people over complicated and the structure is something to get used to. Also the docs contain all sorts of thinks that the general user (even in advanced mode) won't need. We don't have to recommend one set up, there can be multiple options depending on how much convenience you want to trade in for security/privacy. The latter being depended on the persons thread model.

[Ja-ngolo]

Yes, that's part of why I'm asking, ublock's documentation is a bit convoluted and can have a lot of options that even on advanced mode most people won't use. Since privacyguides is a learning resource I think you could help the users explaining the options and relating them to example threat models, so users can be better informed on what type of mode they want to use.

[rusty-snake]

You can also contribute to the upstream docs to improve them 😉

[Ja-ngolo]

Not a bad idea

[jonaharagon]

Personally I only use uBlock Origin's defaults, and I don't really feel comfortable saying whether or not this is better for most people than the defaults, so I will leave that up to you guys to decide.

However, if this configuration makes more sense for most of our website visitors than the default configuration, then yes I think that we should include a guide (under the recommendation card) clearly explaining how this works, why it's better, and showing people how to make these configuration changes, rather than simply linking to the developer's documentation on the feature.

[Ja-ngolo]

I completely agree with your last point, if said configuration is better there should be a section clearly explaining it under the recommendation. However, I do not know which configuration would the site's users would find to be the most appealing to use. Maybe it is a compromise between privacy/security and limiting site breakage. Again I'm not very knowledgeable on this so I would like people in the community to chime in and say if dynamic blocking really is a good step up from the default config. or if the hassle is too much compared to the benefits it can provide.

From the discussion up to this point, the only benefit I can clearly see is that the user switches from enumerating badness to enumerating goodness according to their own uses and preferences. As i read on madaidan's page it enumerating badness apparently does not work (https://madaidans-insecurities.github.io/browser-tracking.html). But also as it has been pointed out the fingerprint protection it could bring is apparently not that much if a user is already using RFP on Firefox (not to mention Firefox already tries to block said fingerprinting scripts) or using Brave's fingerprinting protection.

In the end, i would like to see more opinions and much more informed people chime in before a decision on this is reached.

[rusty-snake]

As i read on madaidan's page it enumerating badness apparently does not work

Of course you will never have a exhaustive list of badness. However the list in uB cover a lot of badness, especially for more frequently visited sites and used trackers so you can get a very good protection even if it can never be perfect.