Open Bug 1666160 Opened 4 years ago Updated 1 year ago

Users enable `privacy.resistFingerprinting` and then are surprised when it causes problems

Categories

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

enhancement

Tracking

()

REOPENED

People

(Reporter: metasieben, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [domsecurity-backlog1])

Ever since privacy.resistFingerprinting was added every guide to harden Firefox
includes this pref, mostly without mentioning the consequences of enabling it has.

AFAIK this was added as part of the TOR-uplift project; while it (might) make sense for
the TOR browser, enabling this in Firefox produces lots of problems and support-request.

Maybe there should be a infobar, similar to the >Your browser is being managed by your
organisation.<, when privacy.resistFingerprinting is enabled, linking to a sumo-article
about the pref(eg. what it does) and how to disable it.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

I think this is worth having this discussion here, since it's slightly different than bug 1490728.

In the past we have sometimes made the pref name scary to avoid scams that say "just set 'browser.require-cors:false' and go to this link!".
I think that would be a good preventative measure if we can find a good name that implies breakage may occur.

"privacy.resist-fingerprinting-so-hard-that-websites-break" is one possibility.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: Add some sort of notification when `privacy.resistFingerprinting` is enabled → Users enable `privacy.resistFingerprinting` and then are surprised when it causes problems
Component: Preferences → DOM: Security
Product: Firefox → Core
Severity: -- → S3
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

Can we rename this pref to something like privacy.resistFingerprinting.mayBreakWebsites or something?

Flags: needinfo?(dveditz)
Flags: needinfo?(dveditz) → needinfo?(tom)

renaming the pref would effectively turn it off for everyone who has gone out of their way to turn it on. That will un-break some people (less annoyance) but would put other people who actually need it at risk and they wouldn't figure that out for quite some time. I could only support a re-name if we also included code to migrate non-default settings to the new name. But otherwise, sure, if you think a new name will help. I think an about:support warning and/or a highlighted note in the "Privacy" section of about:preferences would be better... but those involve l10n so would be a bigger project.

Tor browser would likely be fine since "on" is their default and the renamed pref would also default to "on".

+1. Renaming the pref would also not work for folks who enable this pref by just dropping in an predefined user.js, like the popular arkenfox/user.js (which does try its best to explain what these pref accomplish.) A better solution, as suggested in the initial comment, might be to provide a visual indicator, either something subtle like a badge in the address bar or something more overt like changing the color of the address bar.

Sanketh, arkenfox will be fine, that Thorin is onto it, also Daniel said

I could only support a re-name if we also included code to migrate non-default settings to the new name

+1 for a rename - changes to UI are a PITA

+10 : auto include RFP=true in the user agent when logging bugzillas

Yeah, adding a migration is a sensible thing to do... I'm not a fan of maintaining UI for an opt-in, ideally-rarely-used pref.

I suppose I'm not explicitly against renaming it. I think migration is definitely necessary, but I think a significant number of people get RFP enabled through add-ons (which we are thinking about deprecating also.) I always preferred the visual indicator but after we looked at the telemetry (Bug 1693861) that told that the number of users who had RFP enabled was actually much fewer than we thought we de-prioritized it.

Flags: needinfo?(tom)

Aren't all/most duplicates of this bug actually duplicates of bug 1663586 and caused by privacy.resistFingerprinting.randomDataOnCanvasExtract being true by default?

Please add a big scary warning to the top of this page: https://support.mozilla.org/kb/firefox-protection-against-fingerprinting

Duplicate of this bug: 1827640
Duplicate of this bug: 1849355
No longer duplicate of this bug: 1849355
Duplicate of this bug: 1849355

Having lost 2.5 days to this in a simple HTML5/CSS3 page I agree there needs to be a banner to alert us! I'd prefer to see a warning next to the Settings > Web site appearance options warning that these changes will not take effect due to privacy.resistFingerprinting = true - and as I discovered there is no way to disable it per-tab when the protocol is file:// since there is no shield.

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