Resist Fingerprinting should have option to not force prefers-color-scheme to white
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
I set ui.systemUsesDarkTheme to 1 while having privacy.resistFingerprinting on true.
Feature Request:
Users should have an additional option privacy.resistFingerprinting.forceLightColorScheme which defaults to true, and if disabled, causes prefers-color-scheme to not get pinned to light while RFP is enabled, but use the same logic that non-RFP uses and therefore allows RFP users to have dark mode on certain web pages.
Actual results:
Websites with dark mode support should be shown in dark mode.
Expected results:
Websites with dark mode support are shown in light mode.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 3•3 years ago
|
||
This is kind of expected given the code. I'm not sure to what extent we want to change how this works, allowing to bypass the check basically defeats the point of resistFingerprinting. We could add a more fine-grained pref but... Tom, thoughts?
|
||
Comment 4•3 years ago
|
||
Presently our policy on these requests is that RFP exists for Tor; and (a) they do not need feature-specific overrides and (b) that feature-specific overrides should not override RFP because it will make you significantly more fingerprintable rather than less. (An example of such a pref that already exists, and does not override RFP, is the user agent override.)
I know this is an oft-requested one, so I'm not going to close this outright as wontfix, but we don't intend to change things right now.
|
||
Comment 5•2 years ago
|
||
allowing to bypass the check basically defeats the point of resistFingerprinting
Are you suggesting that to get dark mode working users should completely disable resistFingerprinting in tor browser? - at this point I'm actually considering it, especially if it's the official position of mozilla devs
I'd rather take the minimal risk of being persecuted but keep my eye health which is 100% from getting harmed by this
Im not a sociologist, but given that the RFP use case is seen as predominately for Tor, and Tor is generally perceived as the dark side, would it not be a more suitable fit to have the default being dark mode? no choice necessary, no loss of RFP effectiveness just everyone sharing the same dark setting... then see how many bug trackers get opened from light mode enthusiasts... or do some metric stats tell us that most browsers want white? so even if we all share the darkness there is still a substantial loss in RFPness.
Regardless Dark has my vote, just spoof it bro :D
I`d settle for a force reader mode function and all the brokenness that entails.
Would be great to have this option, even if it's hidden deep inside about:config.
At the moment, the lack of dark mode support is keeping me from using RFP altogether.
|
|
||
Comment 8•5 months ago
|
||
While it's still not a supported configuration, like RFP, I am pleased to report this is now possible. If you disable RFP, enable FPP, and change FPP's behavior to mimic RFP, you can disable the individual color scheme protection.
privacy.resistFingerprinting= falseprivacy.fingerprintingProtection= trueprivacy.fingerprintingProtection.overrides=+AllTargets,-CSSPrefersColorScheme
https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPTargets.inc is the list of targets.
Description
•