When resist fingerprinting is turned on we should probably use the 'no-preference' value for this media feature.

To be clear it's already hard coded to Light which doesn't appear to be a privacy leak perhaps just semantically wrong: https://searchfox.org/mozilla-central/rev/2738efcf98d746c8810819e7c0634b2c57212a8d/layout/style/nsMediaFeatures.cpp#247-248

To me Light is actually a good default, but I can see the argument for NoPreference also.

It's possible that authors may tweak styles specifically for a light preference that are different from no-preference. Though, in practice, most sites probably design for light and only perform adjustments for dark. Still, perhaps no-preference is a slightly better default.

@mats: Thoughts here?

I don't think there will be another browser implementing no-preference from memory, which then would be a vector.

(In reply to :Ehsan Akhgari from comment #0)

When resist fingerprinting is turned on we should probably use the 'no-preference' value for this media feature.

We intentionally chose 'light' because that's the value
the vast majority of clients will report by default.
I don't understand why moving users with anti-fingerprinting
enabled to the small 'no-preference' bucket would help.
It seems to me that would make them stand out since
close to ~100% of clients will report either 'light'
or 'dark'.

(In reply to Mats Palmgren (:mats) from comment #4)

It seems to me that would make them stand out since close to ~100% of clients will report either 'light' or 'dark'.

In theory, it doesn't really matter what the group of privacy.resistFingerprinting (RFP) users actually report, as long as they are all the same. While it would be nice to try and spoof a common value, it is not strictly required.

This is why Tor Browser (TB) works, because all TB users have the same fingerprint (within reason, see [1]). The same principle applies to the set of RFP users. TB is not trying to hide that it is TB, and RFP is not trying to hide that it is RFP.

RFP users are easily identifiable anyway: Canvas will return a 10x10 white canvas. Screen + available screen + outer window and inner window measurements will always be the same, as well as screenX/Y + mozInnerScreenX/Y will always be zero, and so on. There are a number of enforced RFP metrics that end users can't alter, that absolutely 100% reveal RFP is being used. That said, to repeat, it is nice to spoof common values :)

As per comment 2, users may tweak, so enforcement is necessary in order to harden the anti-fingerprinting approach here. What you guys choose is fine with me, as long as it's enforced.

[1] Obviously not everything is patched, and some items are deliberately split (fonts per OS, platform via JS, etc).

OK, good to know. Thanks for elaborating.

I think the arguments presented for choosing 'light' instead of 'no-preference' are convincing, thanks! Closing the bug as INVALID based on the discussion.