1490728 - Improve discoverability/explanation of RFP

Status: NEW

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

Description

[Tom Ritter [:tjr]]

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)

Comment 1

[Artem S. Tashkinov]

This option should NOT override user defined general.*.override values, e.g.

general.appversion.override
general.oscpu.override
general.platform.override
general.useragent.override

Comment 2

[Ethan Tseng [:ethan]]

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

Comment 3

[hello i'm a lizard]

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?

Comment 4

[vtol]

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.

Comment 6

[matthias koplenig [:metasieben]]

As described in Bug 1666160, users enable RFP without being aware of the consequences,
resulting in a slew of support-requests(broken websites, file uploads, wrong timezone, etc).

Any chance we could add some sort of infobar or visible trigger that RFP has been enabled and
what this might entail(sumo-article?).

Comment 7

[Kelsey Gilbert [:jgilbert]]

I re-opened bug 1666160 to discuss the specific issue of users often inadvertently harming their experience while trying to do the right thing.