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] Privacy considerations. #3488

Open
mikewest opened this issue Jan 7, 2019 · 7 comments
Open

[mediaqueries-5] Privacy considerations. #3488

mikewest opened this issue Jan 7, 2019 · 7 comments

Comments

@mikewest
Copy link
Member

mikewest commented Jan 7, 2019

It would be helpful to add a privacy considerations section to this spec, noting that some of the queries reveal interesting information about a user's preferences, which can be useful when building a fingerprint of the user's browser. Consider, for example, the hypothetical user who browses on their bathroom mirror, while inverting colors, preferring reduced motion and transparency, more contrast, and dark mode vs a perhaps more typical user who doesn't change any defaults at all.

Thanks!

@lilles
Copy link
Member

lilles commented Jan 7, 2019

Yes, the level 5 draft says it did not yet copy sections from level 4 on purpose according to the note in [1]. Level 4 currently has [2]. Does that address your concern if copied to level 5?

[1] https://drafts.csswg.org/mediaqueries-5/#intro
[2] https://drafts.csswg.org/mediaqueries-4/#priv-sec

@mikewest
Copy link
Member Author

mikewest commented Jan 7, 2019

Ah! Thanks. I missed that note entirely.

I think it would be helpful to spell out the risk in a little more detail. The text in level 4 is pretty high-level and while I think I agree with the assertion that the risk is generally low (especially in light of every other way the platform reveals detail about the user's environment), I'd suggest pointing out the ways in which the level 5 queries are user-specific, rather than device-specific. They really do seem different in kind, given their relation to the way a user configures their computer (dark mode or accessibility features), rather than aspects of the computer itself (aspect-ratio, width, height, etc).

It also seems that the answer to "access to sensors" would change, given the ambient light query?

@fantasai fantasai changed the title [css-mediaqueries-5] Privacy considerations. Jan 16, 2019
@svgeesus
Copy link
Contributor

As discussed on the CSS telcon 2019-04-24, the Security and Privacy section needs to be added, and to be updated w.r.t the level 4 spec to cope with the privacy aspects of the color-mangling stuff.

@frivoal
Copy link
Collaborator

frivoal commented Jul 30, 2020

There is some information in the spec about privacy (https://drafts.csswg.org/mediaqueries-5/#mq-prefers-security), but it's inadequate. As those responsible for writing one (that includes me) haven't been making progress, help would be very much appreciated.

@cookiecrook
Copy link
Contributor

Linking an old Media Features Privacy Model proposal from the now-defunct IndieUI User Context draft.
https://www.w3.org/TR/indie-ui-context/#privacy-model

In the TPAC 2020 CSS/APA joint meeting today, @gzimmermann requested I link this in the context of APA's user preferences wishlist for querying AT features. cc @digilou @JaninaSajka @frivoal

@lukewarlow
Copy link
Member

lukewarlow commented Jul 26, 2023

Hi, I'm currently implementing some of MQ-5 in Chrome (namely prefers-reduced-transparency and inverted-colors). The intent to ship process for PRT has raised this as a concern hence why I'm here.

I agree it would be good to replace the issue block with actual analysis of the impact of the impact.

Of the 5 prefers-* queries prefers-reduced-motion, prefers-contrast, prefers-color-scheme have been implemented across the board.

forced-colors a similar fingerprinting vector has been implemented across the board.

inverted-colors another fingerprinting vector has been implemented in WebKit for some time.

Across all of this I'm assuming there should be enough data to evaluate the risk? It would be good to get some information on what this data would actually look like? As in what's the end goal of the replacement for this issue?

I see the main benefits of the outcome of this issue coming in the form of evaluating any unimplemented queries and any new preference media queries that may be wanted, as opposed to being able to change what's already exposed.

Unimplemented:

prefers-reduced-data has an experimental implementation inside of Chromium. This would be exposing new information for Firefox and WebKit but NOT for Chrome (Save-Data header and NetworkInformation.saveData)

prefers-reduced-transparency has shipped in chromium and has an experimental implementation inside of Firefox.
It is exposed to native applications on Windows, macOS and iOS, the three platforms with explicit settings for this.

inverted-colors as mentioned above is exposed in Safari, an experimental implementation exists in Firefox and an experimental implementation is being added to Chrome.

See #7406 and #8651 for examples of potentially new preference MQs

@lukewarlow
Copy link
Member

Based on discussion in various other places we've come back to here (I think this is the best issue to discuss it in)

But basically it'd be good to come up with a solution to the privacy problems.

One proposal was to have the media queries default to the no-preference state. And only once the user explicitly opts-in to sharing this data with sites would the true value be exposed. (Color-scheme shouldn't be included in this imo). A concern with this approach is how do you present the opt in UI so the user can provide informed consent. Aka they know they're trading privacy for accessibility.

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