Closed Bug 1535189 Opened 6 years ago Closed 6 years ago

Let ui.systemUsesDarkTheme set prefers-color-scheme regardless of resistFingerprinting

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: johnp, Unassigned)

References

Details

Currently prefers-color-scheme is stuck to light once resistFingerprinting is enabled, making it impossible for users to both communicate their color preference to a website and enable general fingerprinting resistance.

Explicitly setting the pref ui.systemUsesDarkTheme should probably override the privacy.resistFingerprinting default-to-light.

See Also: → 1529323

I'm not sure to which extent we usually allow to bypass privacy.resistFingerprinting... Ethan, do you know if this would be acceptable to do?

Flags: needinfo?(ettseng)

I think exposing preference values other than default values could be used for fingerprinting..

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)

I think exposing preference values other than default values could be used for fingerprinting..

Right...

To be clear: I only propose that users can explicitly opt-in via creating a, by default hidden, preference to willfully disclose a chosen preferred color scheme and still be able to use Firefox's general fingerprinting resistance. (ui.systemUsesDarkTheme offers itself since it is already used in that context and is hidden)

One could also or instead overload ui.systemUsesDarkTheme with another, entirely new integer value that explicitly says: Use the metric decided in bug 1529323, regardless of resistFingerprinting.

privacy.resistFingerprinting already has various papercuts that prevent some users that would like to at least partially benefit from it from using it (e.g. the default 1000x1000px(?) window size on restore), I'd just like to avoid adding even more.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

I'm not sure to which extent we usually allow to bypass privacy.resistFingerprinting... Ethan, do you know if this would be acceptable to do?

Forward the question to Tom and Georg who have better insight than me.

Flags: needinfo?(tom)
Flags: needinfo?(gk)
Flags: needinfo?(ettseng)

Doing so would be moving away from our previous decisions about RFP, which is essentially that nothing overrides it. The reason behind that choice is to create a single pref that when set, fixes everything else (to the extent it is complete or possible) to make you resist fingerprinting.

Eventually, something will make us reconsider this position, but I don't think this one is high value enough to do so. I think this is WONTFIX

Flags: needinfo?(tom)

I'm ok with that.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(gk)

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories]) from comment #6)

Eventually, something will make us reconsider this position, but I don't think this one is high value enough to do so. I think this is WONTFIX

Would appreciate the bug to be reopened and the position to be reconsidered, because:

  • it breaks the dark mode Lockwise's about:logins, which is internal and thus distorts the coherency of the browser's dark theme
  • there are more decisive characteristics for fingerprinting than whether a light or dark theme is in play, which is basically 50/50 and nothing really gained by breaking prefers-color-scheme

Breaking the integrity of RFP is not necessarily the answer. For Lockwise see Bug 1450398 .. i.e some/all RFP features shouldn't apply to extensions and/or privileged content / Firefox core - here's another one: Bug 1377744

  • Neither of those two cited bugs relate to this specific issue (prefers-color-scheme = web standard).
  • Lockwise is not a WX but integral part of FX as is about:logins.
  • RFP breaking web (compatibility) standards can hardly be the direction
  • other RFP implementations do not break web standards but this one clearly does
  • other RFP implementations do not break the coherency of FX's theme but this one clearly does

This thread has not explained the gain/benefit of breaking prefers-color-scheme, it hardly matters in the scheme of fingerprinting whether the a light or dark theme is detected.

(In reply to vtol from comment #11)

  • Neither of those two cited bugs relate to this specific issue (prefers-color-scheme = web standard).
  • Lockwise is not a WX but integral part of FX as is about:logins.

I think the right course of action is to file a bug about how RFP is applying to Lockwise when it shouldn't.

  • RFP breaking web (compatibility) standards can hardly be the direction
  • other RFP implementations do not break web standards but this one clearly does

RFP violates web standards all over the place actually. We explicitly do so in the name of user intervention - the user has opted into a mode that has reduced compatibility on the web and breaks some features but provides greater privacy. At some point in the future it would be wonderful if RFP and Web Standards converged again - but it's going to have to be Web Standards that come to meet RFP - not the other way around.

  • other RFP implementations do not break the coherency of FX's theme but this one clearly does

This thread has not explained the gain/benefit of breaking prefers-color-scheme, it hardly matters in the scheme of fingerprinting whether the a light or dark theme is detected.

Fingerprinting is a game of numbers. We can't hide your browser resolution entirely, so you get put into a bucket based on that. OS is the same. There's a few others. While light/dark seems small - it adds to the other items. And since it's likely a minority of people use dark theme (5% 15% 25%?) those who do expose that they are dark mode are put into an even smaller bucket.

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories]) from comment #12)

I think the right course of action is to file a bug about how RFP is applying to Lockwise when it shouldn't.

bug 1588548

At some point in the future it would be wonderful if RFP and Web Standards converged again - but it's going to have to be Web Standards that come to meet RFP - not the other way around.

That seems to be curious idea since there is no indication by the web consortium and other browser developers to ever head in such direction.

Fingerprinting is a game of numbers. We can't hide your browser resolution entirely, so you get put into a bucket based on that. OS is the same.

Neiher of which really breaks web compatibility.

There's a few others. While light/dark seems small - it adds to the other items. And since it's likely a minority of people use dark theme (5% 15% 25%?) those who do expose that they are dark mode are put into an even smaller bucket.

Those numbers are actually facts or more of a gut feeling?

Returning nothing on @media queries is a fingerprint characteristaca in its own and puts the user already in the minority - that is a guess and not a fact based on research.

(In reply to vtol from comment #13)

Those numbers are actually facts or more of a gut feeling?

Gut :)

Returning nothing on @media queries is a fingerprint characteristaca in its own and puts the user already in the minority - that is a guess and not a fact based on research.

Yes - we don't hide the fact that you are in the RFP bucket, we just try to put as many RFP users in the same bucket as possible.

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories]) from comment #14)

Yes - we don't hide the fact that you are in the RFP bucket, we just try to put as many RFP users in the same bucket as possible.

Perhaps a misconception my end then, reckoning that the RFP design goal is to generate the highest possible entropy in order to achieve the least distinguishability.

I think that this should be fixed by adding configuration for it (though not exactly as proposed in the title, see below[1] ), in the name of user freedom and customizability, as well as to promote the usage of, rather than hinder, the still-emerging, welcome prefers-color-scheme standard. As mentioned, RFP itself exists to enforce user choice and freedom in the first place (well, in more ways than one). Explicitly, in enabling or disabling RFP, the user is already choosing between tradeoffs, which is why it's not forced to be on for everyone. Yes, changing your "public-facing color scheme" from the RFP-default could act as a vector to lower your fingerprinting resistance. I won't repeat points already made. Let the user choose. And allow the user to be able to make a better choice than "either break site dark theming and color consistency across browser and potentially burn my eyes, or completely disable RFP altogether".

[1] I feel this should be handled by a new pref under privacy.resistFingerprinting.* that dictates the exposed prefers-color-scheme value in contexts in which RFP is currently active. For example, a string privacy.resistFingerprinting.announced-color-scheme (or whatever other name) that can be set either to directly 'outbound' values ("no-preference", "light", "dark", possible future additions) which always forces that output to websites, or to a special other value (e.g. "auto" or "default" or a more unique word/symbol/string) that causes the normal current preferred color scheme to fall through to websites, i.e. with this value Firefox will fall back to broadcast same value as it would have if RFP was off. To maintain the current behavior, this new pref privacy.resistFingerprinting.announced-color-scheme would have the default value of "light", though giving it the 'auto' value by default instead might be better overall, especially if it can be assumed that dark mode users are not as rare among RFP users; this will make the default RFP profile be more diverse in color-scheme vector and may lead to normalizing the 'RFP resistance hit' among light- and dark-color-scheme users so dark users don't stand out as much after all, with perhaps practically only net benefits. An idea to consider. You could also make this pref a little simpler but less flexible by making it a boolean instead, where one value leaks the user's browser color scheme and the other spoofs it to a hardcoded "light" value like right now.
Adding this new pref is more robust and stays consistent with the direction of "turning on RFP takes precedent over all other settings" (except privacy.resistFingerprinting.* sub-settings) as well. There are already other privacy.resistFingerprinting.* prefs that allow tweaking observable RFP behavior and thus altering or narrowing the fingerprint, so it'd be nothing new there.

This is part of metabugs https://bugzilla.mozilla.org/show_bug.cgi?id=1401440 and of course https://bugzilla.mozilla.org/show_bug.cgi?id=565512. Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1450398.

Only mentioning this since I'm suffering from it this very moment - funnily enough, having RFP on "breaks" this very site in the current state of things, as a manual dark theme toggle here doesn't seem to exist as on other sites (or I can't find it), so I'm fatiguing my eyes writing this at night on an otherwise dark browser and OS.

RFP makes internal "Hmm. We’re having trouble finding that site." pages white (ignore ui.systemUsesDarkTheme) when everything else is night mode. Is that a bug or also a mitigation against fingerprinting?

(In reply to woky from comment #17)

RFP makes internal "Hmm. We’re having trouble finding that site." pages white (ignore ui.systemUsesDarkTheme) when everything else is night mode. Is that a bug or also a mitigation against fingerprinting?

Bug, it shouldn't apply to system pages. It's Bug 1588548

Regressions: 1588548

Even using the inspector (with devtools.inspector.color-scheme-simulation.enabled) is overridden by privacy.resistFingerprinting.

Resist Fingerprinting should not override actions that are explicitly taken using the dev tools.

Um, this is an accessibility thing. Ask a legally blind guy who has photophobia. (Hi, I'm legally blind and have photophobia—bright lights ACTIVELY CAUSE PAIN.) You're insisting that I may have accessibility for the disabled, or still quite imperfect privacy protections, but not both.

Still quite imperfect: With fingerprinting resistance, it is still trivial to discern that my browser is lying about both its version and what operating system/architecture I'm using (that is, it can tell that I'm using Linux x86_64, but claiming I use Windows 32 bit), reports a font list most Linux systems have, but lacks standard Windows fonts, allows DNT to show or not (even though it's actually a useless setting except for tracking purposes), and reports a non-randomized but determinably spoofed screen resolution.

I'm asking for reconsideration because I do not believe this feature leaks much information, because it should not be partially enabled and then disabled resulting in breakages, because it should not break dev tools, and because there is a moral (and when it comes right down to it, a legal) obligation to support users with disabilities. It might be good to include a note if you explicitly enable both dark theme and fingerprint resistance that choosing the dark theme necessarily leaks this information to websites. (No need for a warning in the dev tools I'd argue, since the dev tools are a temporary enable made by a developer trying to explicitly request the feature.

I don't object to having to enable ui.systemUsesDarkTheme or something like that either, but whatever fix is employed ought to fix other internal issues as well.

(In reply to Joseph Carter from comment #20)

Still quite imperfect: With fingerprinting resistance, it is still trivial to discern that my browser is lying about both its version and what operating system/architecture I'm using (that is, it can tell that I'm using Linux x86_64, but claiming I use Windows 32 bit), reports a font list most Linux systems have, but lacks standard Windows fonts, allows DNT to show or not (even though it's actually a useless setting except for tracking purposes), and reports a non-randomized but determinably spoofed screen resolution.

This is correct. RFP in Firefox is imperfect; it is made to be used inside Tor Browser; where these imperfections have less of an impact.

I'm asking for reconsideration because I do not believe this feature leaks much information, because it should not be partially enabled and then disabled resulting in breakages, because it should not break dev tools, and because there is a moral (and when it comes right down to it, a legal) obligation to support users with disabilities.

Because RFP is not a supported configuration of Firefox, we make a best-effort mechanism to maintain and develop it, but ultimately it is a free-time-development sort of configuration.

I think your concern and request is reasonable; and if Tor Browser decided to change their behavior (or decide on a new desired behavior, even if not developed) we could try to adopt or implement that change.

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