Open Bug 1490728 Opened Last year Updated Last month

Improve discoverability/explanation of RFP


(Core :: DOM: Security, enhancement, P3)





(Reporter: tjr, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [tor][fingerprinting][domsecurity-backlog1][fp-triaged])

When Resist Fingerprinting is enabled, we will override prefs and lock down other options.

For a truly hard-core RFP mode, we need to do a better job of identifying what prefs we need to override.

But we should also enable some form of discovery for users - a console notification or a tab or something that explains what RFP is doing (on the web) and what it has negated in the browser (user-set prefs, possibly disabling extensions if we decide to do that, etc)
Whiteboard: [tor][fingerprinting]
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][domsecurity-backlog1]
This option should NOT override user defined general.*.override values, e.g.

1. This bug is likely to require UI/UX support.
2. We need to trace code base to identify all the prefs overridden by RFP.
Whiteboard: [tor][fingerprinting][domsecurity-backlog1] → [tor][fingerprinting][domsecurity-backlog1][fp-triaged]

Agree with Artem, and disagree (strongly) with Tom who is exhibiting Google/Microsoft-esque 'we know better than the user' thinking.

If I set an override, I expect my decision to be honoured. If I was happy to use the default, I wouldn't have set the override.

What rationale has been given, to disallow the user having the ability to override resist fingerprinting defaults? What use case that causes harm, is this policy attempting to rectify? What is wrong with giving sensible defaults to RFP, but allowing a user to make a conscious informed choice to override them, when the defaults aren't appropriate for them?

What percentage do you imagine would override RFP defaults, that you're attempting to stop by this decision? 1%? 5%?

Are you claiming that you're not satisfied with a general pool of 95 or 99% having an identical fingerprint, that you NEED a full 100% and to do so, you consider it justifiable to remove users ability to opt-out from this pool? Especially, due to the defaults you've picked, you've put them in a tiny pool?

Case in point of acting as guardian to the user is bug 1535189 which is even breaking the brower's dark theme for about:pages

I concur with :Artem S. Tashkinov & :i'm a lizard that knowing better(aka hard coded) than the user seems not the right approach.

You need to log in before you can comment on or make changes to this bug.