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

RESOLVED WONTFIX

Status

()

enhancement
RESOLVED WONTFIX
4 months ago
3 months ago

People

(Reporter: johnp, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

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: 4 months ago
Resolution: --- → WONTFIX
Flags: needinfo?(gk)
You need to log in before you can comment on or make changes to this bug.