Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mediaqueries-5] Ability to retrieve the original value of an overridden preference #11580

Open
lukewarlow opened this issue Jan 27, 2025 · 2 comments

Comments

@lukewarlow
Copy link
Member

Copied from:WICG/web-preferences-api#38

(Copying from a mastodon thread with some rewording — https://front-end.social/@kizu/113160248251763608)

There are legit cases when you'd want to override the value that is used everywhere, but then still be able to differentiate how things look/behave based both on the original value, and on the override. See https://blog.kizu.dev/querying-the-color-scheme/#not-the-user-preference, for example — it is very similar to what we'll have with the web preferences.

With the way things are specified right now, we could do it in a hacky way: clear the override, read the value, restore the override, but that feels very cumbersome and inconvenient.

It would be great if we could get the original value natively (and also monitor it similar to matchMedia maybe).

cc @kizu

@bramus
Copy link
Contributor

bramus commented Jan 27, 2025

As replied on the original issue, I think this would increase the ways to track a user:

While I understand the use-case, this — unlike the override itself — would add an extra bit of tracking data.

By only having access to the overridden value, entropy is added to the tracking data. If we were to expose the original value, the opposite happens.

By exposing the original + the overridden value, one can single out users who have overridden the preference.

@lukewarlow
Copy link
Member Author

By exposing the original + the overridden value, one can single out users who have overridden the preference.

You can already determine that based on the current API design? navigator.preferences.colorScheme.override will be null if it's the original value or set if its overridden.

While you can't determine the OS value at the same time as the override you can just clear the override read the value and set the override again. I don't think it's introducing anything novel wrt fingerprinting?

Having said all that I think my main question is what are the use cases? Are they valid enough for the potentially extra complexity (especially if we have to track changes to both)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants