Intent to implement: CSS media queries, interaction media features

[Thomas Wisniewski]

Summary: Implement the CSS features [any-]pointer:{none|coarse|fine} and
[any-]hover:{none|hover} in a manner that is compatible with Blink. These
features are implemented in all other major engines including Edge, and
sites like Gmail are now using them. Our lack of support for these features
has also caused some developer friction, especially since our proprietary
-moz-touch-enabled feature seems to have flown completely under the radar.

Bug: 1035774

Link to standard: https://dev.w3.org/csswg/mediaqueries4/#mf-interaction

Platform coverage: Windows, OSX, Linux and Android (though OSX/Cocoa seems
to have no APIs to expose this information, so we will fall back to the
same "user only has a mouse" values that Blink and WebKit use on OSX).

Estimated or target release: Firefox 58.

Preference behind which this will be implemented:: None.

Is this feature enabled by default in sandboxed iframes? Yes.

Tests: only for the CSS parsing (similar to how -moz-touch-enabled is
currently tested). We do not currently have any testing infrastructure to
mock the OS calls for full test coverage. Nor do the Web Platform Tests
(and there are no bugs yet made against the WPTs to add them). Given that
other vendors have long shipped this regardless, and there have been no
major interop issues, I don't suspect this needs to be blocked on such
tests.

How stable is the spec: the last point of contention that I'm aware of was
resolved by other vendors a year ago when the "on-demand" feature was
dropped from the draft spec.

Security & Privacy Concerns: this exposes whether the user has pointer that
is finely controlled like a mouse, or more coarse-grained like a
touchscreen (or no pointer at all). It also exposes whether they have a
pointer capable of "hover" effects (like a mouse). This lets sites
distinguish between the user having a mouse-like device or touchscreen-like
device, and potentially other devices like stylii. It exposes a little more
fingerprintable information than -moz-touch-enabled, however it would be
trivial for anti-fingerprinting measures to always return a specific set of
values for mobiles vs desktops.

Web designer / developer use-cases: Allowing sites to definitively know
whether the user has a touch-capable device, mouse-like device, or
stylus-like device (or all three), so that appropriate styles can be served
for each case without having to resort to flimsier scripts to guess at
those capabilities.

[Tom Ritter]

On Tue, Oct 3, 2017 at 3:12 PM, Thomas Wisniewski <wisni...@gmail.com> wrote:
> Security & Privacy Concerns: this exposes whether the user has pointer that
> is finely controlled like a mouse, or more coarse-grained like a
> touchscreen (or no pointer at all). It also exposes whether they have a
> pointer capable of "hover" effects (like a mouse). This lets sites
> distinguish between the user having a mouse-like device or touchscreen-like
> device, and potentially other devices like stylii. It exposes a little more
> fingerprintable information than -moz-touch-enabled, however it would be
> trivial for anti-fingerprinting measures to always return a specific set of
> values for mobiles vs desktops.

Will those measures be part of the work done (enabled only when
privacy.resistFingerprinting is set)?

-tom

[Emilio Cobos Álvarez]

On 10/03/2017 10:12 PM, Thomas Wisniewski wrote:> Security & Privacy

Concerns: this exposes whether the user has pointer that
> is finely controlled like a mouse, or more coarse-grained like a
> touchscreen (or no pointer at all). It also exposes whether they have a
> pointer capable of "hover" effects (like a mouse). This lets sites
> distinguish between the user having a mouse-like device or touchscreen-like
> device, and potentially other devices like stylii. It exposes a little more
> fingerprintable information than -moz-touch-enabled, however it would be
> trivial for anti-fingerprinting measures to always return a specific set of
> values for mobiles vs desktops.

Note that the system metric media queries respond to the
privacy.resistFingerprinting pref. I think we should keep doing the same
for this one.

-- Emilio

[twisn...@mozilla.com]

> Will those measures be part of the work done (enabled only when privacy.resistFingerprinting is set)?

If we want them to be, sure. I don't mind adding a patch to do so as part of the initial landing rather than a follow-up.

Bear in mind that I'm operating on the presumption that we would want anti-fingerprinting to always return values for Windows/OSX/Linux that convey there is only a fine, hover-capable pointer (a mouse), and on Android to convey that there is only a coarse, non-hover-capable pointer (a touchscreen). If that's not good, then please let me know.

>Note that the system metric media queries respond to the
privacy.resistFingerprinting pref. I think we should keep doing the same
for this one.

Agreed.

[fantasai]

On 10/03/2017 01:12 PM, Thomas Wisniewski wrote:
> Summary: Implement the CSS features [any-]pointer:{none|coarse|fine} and
> [any-]hover:{none|hover}

> ...

> How stable is the spec: the last point of contention that I'm aware of was
> resolved by other vendors a year ago when the "on-demand" feature was
> dropped from the draft spec.

The spec is in CR, which in the CSSWG represents a consensus that the draft
is design-complete and vendors are encouraged to ship in public releases.
https://www.w3.org/TR/mediaqueries-4/
https://www.w3.org/TR/CSS/#unstable

~fantasai