Revisit Resist Fingerprinting with respect to accessibility issues (e.g. prefers-color-scheme)
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
People
(Reporter: forestix, Unassigned)
Details
Steps to reproduce:
privacy.resistFingerprinting = true
Actual results:
[This new report was requested in bug 1450398 comment 44.]
With Resist Fingerprinting enabled, sites designed to respect prefers-color-scheme are now forced into bright colors, which are physically painful.
Some people need dark color schemes. It's not merely a style preference, but rather the difference between reading comfortably vs. straining against an eye-watering, headache-inducing interrogation lamp, or worse. For such people (and for those who just strongly prefer dark themes) a privacy setting that breaks prefers-color-scheme is a privacy setting that will not be used. I think Firefox can do better than that.
It occurs to me that the Resist-Fingerprinting policy to block media queries was likely made with high-variance queries in mind. For example, color-index, resolution, and height have many possible values, translating into many bits of data that can contribute to a fingerprint, so disabling them in RFP mode makes sense. On the other hand, supporting prefers-color-scheme requires only two possible values; a single bit. Since it has a uniquely high impact on usability and low value to fingerprinting, I think it deserves special treatment.
I believe this must be fixed in the browser, rather than with an extension, because:
- Such extensions often work badly, causing various problems ranging from extreme contrast to nearly invisible page elements.
- The results are seldom as pleasant as site-provided dark color schemes.
- The results are never what the site designer intended.
- Each installed extension expands the browser's attack surface.
- Each installed extension (last time I checked) further expands the browser fingerprint.
As Joseph Carter points out in bug 1535189 comment 20, "this is an accessibility thing. Ask a legally blind guy who has photophobia." I believe Mr. Carter's point is an important one, easily overlooked or dismissed by people who have never experienced it themselves.
It's worth noting that although prefers-color-scheme only works on sites that support it, more site authors are gradually doing so as they become aware of it and find time to adopt it. This is especially true for sites that cater to people with accessibility needs. I support it on my sites, and would like my users to benefit from that work, including those who are privacy-conscious.
Some ideas for improving on the current behavior:
Suggestion 1 (Easy): Always support prefers-color-scheme. Note that while this would split the RFP "bucket" of users into two buckets, it would also increase the total number of RFP users, further reducing this single bit's already-low value to fingerprinting.
Suggestion 2 (Hidden Option): Add a hidden setting to make RFP respect prefers-color-scheme, and keep the current behavior by default. This would make RFP viable for people who need dark colors, again adding to the total number of RFP users, but without significantly reducing the number of users in the main bucket, since only those who need dark colors would be likely to place themselves in the other bucket.
Suggestion 3 (Balancing): Add a hidden setting to make RFP respect prefers-color-scheme, disabled by default and as visible or hidden as the RFP setting itself. By default, randomly choose light or dark for prefers-color-scheme and make it persist across sessions for UX consistency. The idea here is to allow people who need a dark (or light) scheme to have what they need, while distributing people who don't care among the two buckets. This would increase the total number of RFP users while keeping the buckets roughly equal in size.
Suggestion 4 (Always Dark): Continue pinning all RFP users to a single prefers-color-scheme value, but make it the one that doesn't cause pain: the dark one.
Expected results:
prefers-color-scheme should have been respected, allowing me to use my regular sites without eye strain and headaches.
|
||
Comment 1•2 years ago
|
||
Well, the ticket was more along the lines of Revisit RFP + Accessibility, and depends on Tor Browser's input - prefers-color-scheme is not the full picture (or even widely used by websites). Perhaps a better title? Also:
Tor Browser issues
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40337
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026
Meta
|
||
Comment 2•2 years ago
|
||
Is there any update on this?
I see more and more sites supporting dynamic theming every day, and more users a switching to dark mode too, which should reduce the impact on fingerprinting. It's a little annoying that I have to pick between having privacy protections enabled and having working theming.
I feel that the default behavior is fine, but it would at least be nice to have a about:config option to expose the prefers-color-scheme value even with RFP enabled (similar to other privacy.resistFingerprinting.* options)
|
||
Comment 3•2 years ago
|
||
(In reply to Rhys Perry from comment #2)
I feel that the default behavior is fine, but it would at least be nice to have a about:config option to expose the prefers-color-scheme value even with RFP enabled (similar to other privacy.resistFingerprinting.* options)
So to be clear, there are no other options. There's currently no mechanic to exempt a particular API from RFP. There are prefs of the form privacy.resistFingerprinting.foo but none of them do that. This is because if you had RFP enabled and then exempted a particular API, you would have a unique or almost-unique fingerprint on the Internet. RFP would have made you more fingerprintable, rather than less.
We are developing an RFP Lite type mode, primarily for testing purposes right now, that will not enable all the RFP protections, and color scheme will absolutely be one we don't enable. Since RFP is already an unsupported pref, I imagine switching to an unsupported RFPLite pref would be amenable, so you can watch bugs attached to Bug 1815307 to see how that progresses.
This might be wildly out of scope, but would it be feasible to separate the version of the DOM modified by accessibility settings or relevant/selected extensions from the version that's accessed by everything else (the site's original JS code, FP scripts, normal extensions, etc)? The private "accessible DOM" could be reconstructed from the original every time there's a re-draw by re-applying its modifications on top of the re-drawn original to avoid potential de-syncing of UI elements, while leaving the original untouched (and therefore fully protected by RFP even in the presence of an extension like Dark Reader). This has the obvious drawback of storing 2 copies of the DOM in memory, and it might have some perf implications for complex transformation sets, but those are trade-offs I'd happily opt in to if it meant I could get full RFP protections without having to risk migraines to do it.
I have never written or contributed to a web engine and my experience with web development is minimal, so there might be reasons I'm unaware of that this just won't work. But trying to come up with a sufficient subset of accessibility options to meet most potential needs without creating too many FP buckets feels like a losing battle to me. If I can't use RFP with accessibility features/extensions that modify a website's final displayed DOM because the site could detect that I've modified it and use that to create a more unique fingerprint, it seems to me the solution is to hide those modifications from the website, not to limit them to a low enough number of possible permutations to still get large enough user buckets to prevent unique identification. Part of securing privacy is limiting external access to unnecessary data, and I think that use of a dark mode (or increased text size, or a dyslexia friendly font, or most other accessibility features that modify preexisting DOM elements) falls cleanly in the category of data that does not need to be exposed to the internet.
(I do realize this would not solve the OPs desire to use site-implemented dark themes by passing prefers-color-scheme, but assuming most sites that implement a dark theme do so by just changing color values for each element, it seems it would be pretty straight forward to write an extension that collects those color transformations once and allows re-applying them to the site's private "accessible DOM" during later sessions without needing to pass that flag again).
|
|
||
Comment 5•1 year ago
|
||
I do not think that approach is feasible at this time. But to provide an update on Comment 3: it is now possible to exempt an individual API from RFP, however doing so is generally no recommended (and kind of complicated.)
Firstly, instead of enabling RFP, you would disable RFP and enable privacy.fingerprintingProtection which allows more fine grained control, in a way that RFP does not.
Then you would set privacy.fingerprintingProtection.overrides to +AllTargets,-CSSPrefersColorScheme. The AllTargets tells it to enable all of the RFP Targets (which emulates RFP) and then the second one disables one particular target. The list of targets is here.
Because RFP is a Tor feature we carry in Firefox, unless Tor requests the behavior to change, we will not change it.
On the flip side, FPP (privacy.fingerprintingProtection) is a Firefox feature that we do support. This is the more tested, more conservative behavior that you may wish to switch to, and if you find accessibility problems in it (specifically, accessibility problems in its default configuration, with no values in the .overrides pref) please do file a bug and report them. Presently, Color Scheme is not overridden by FPP.
Accordingly I am going to close this as WONTFIX.
Description
•