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

Status: RESOLVED FIXED

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

Description

[matthias koplenig [:metasieben]]

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.

Comment 2

[Kelsey Gilbert [:jgilbert]]

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.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

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

Comment 9

[Daniel Veditz [:dveditz]]

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".

Comment 10

[sanketh]

+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.

Comment 11

[Thorin [:thorin]]

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

Comment 12

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 13

[Tom Ritter [:tjr]]

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.

Comment 15

[Darkspirit]

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

Comment 18

[08xjcec48]

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

Comment 22

[TJ]

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.

Comment 23

[Neha Kochar [:neha]]

Does the warning banner (bug 1841116) suffice the warning we want to give users, as requested in this bug? Or is there more to do here to keep it open?

Comment 24

[Tom Ritter [:tjr]]

We ran the usage stats for RFP. It's about .02%. There's probably overlap between people who enable RFP and disable Telemetry, but I don't know if there's much we can do about that.

There's more we could do, but I'm not sure the effort is worth the benefit. I do think we should update the FPP SUMO page and the RFP SUMO Page (Bug 1862173) - I'm not sure what has stalled those.

Comment 25

[Frederik Braun [:freddy]]

I think this can be closed. Some follow-up questions though...

Should we deprecate controlling the resistFingerprinting pref through add-ons if we think this is an unwise thing to set?
Should we make a switch to FPP instead?

Comment 26

[Thorin [:thorin]]

not sure if we want to close it, it's good to be cc'd on to find new reports when they're linked

as for no longer allowing extensions to change RFP (I think we could allow them to read it) +100

Comment 27

[u758202]

not sure if we want to close it, it's good to be cc'd on to find new reports when they're linked

We also link to this page when users create forum threads asking for help with issues that were actually caused by enabling this preference (like sites being "suddenly" letterboxed, captcha errors, etc.). Please keep it open, as new users keep following "hardening" guides or using forks that enable it.

Comment 29

[Tom Ritter [:tjr]]

Attachment: Bug 1666160: Direct users in the warning box to the new RFP-specific support page r?freddyb

Comment 30

[Tom Ritter [:tjr]]

We have improved the FPP and RFP SUMO pages, and implemented a warning in the preferences page that will link to the SUMO page with instructions for how to disable it. As users report issues on WebCompat, Bugzilla, Matrix, or other channels, we should direct people to this new page which will hopefully help people avoid repeating themselves too much each time.

https://support.mozilla.org/en-US/kb/resist-fingerprinting

We can continue referencing this bug in bugzilla reports (I think See Also and RESOLVED-INVALID are the best ways to do this)

When this patch lands this bug will be closed.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b1c1d871b515
Direct users in the warning box to the new RFP-specific support page r=settings-reviewers,mossop

Comment 32

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/b1c1d871b515