Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[stone...@gmail.com]

We plan to enable Pointer Events for mouse, touch and pen input in Firefox Nightly builds (on Mac and Linux) within the next few weeks.

Related Bugs:
Bug 960316 - Enable W3C Pointer Events and touch-action CSS property by default
Bug 1352278 - [Pointer Event] Turn on PointerEvent preference on Mac and Linux nightly

Link to standard:
https://w3c.github.io/pointerevents/

Platform coverage: Mac and Linux

Target release: Undefined. It depends on if there are some regressions.

Preference behind which this is implemented: dom.w3c_pointer_events.enabled

Do other browser engines implement this?
Edge and Chrome already ship it.

Tests: WPT

Security & Privacy Concerns: none

Next:
We plan to ship it to all the desktop platforms altogether, as we see it's stable enough on nightly for a while.

[L. David Baron]

On Tuesday 2017-04-04 20:29 -0700, stone...@gmail.com wrote:
> We plan to enable Pointer Events for mouse, touch and pen input in Firefox Nightly builds (on Mac and Linux) within the next few weeks.
>
> Related Bugs:
> Bug 960316 - Enable W3C Pointer Events and touch-action CSS property by default
> Bug 1352278 - [Pointer Event] Turn on PointerEvent preference on Mac and Linux nightly

The dependency trees of these bugs seem like they could use somewhat
better organization, so that people can see what issues are
remaining when evaluating whether enabling on nightly is
appropriate.

For example, if bug 1352278 and bug 1315189 blocked bug 1166347,
then they and their dependencies would all show up in the dependency
tree of bug 960316 (which presumably means enabling in all channels
by default). (In general, if bug A needs to happen before bug B (or
bug A needs to be uplifted in order to uplift bug B), then bug A
should block bug B.)

> Link to standard:
> https://w3c.github.io/pointerevents/
>
> Platform coverage: Mac and Linux
>
> Target release: Undefined. It depends on if there are some regressions.

It seems like shipping further than nightly should also depend on
being ready to do so on all platforms. Otherwise the Firefox
inconsistency between platforms will be confusing for Web
developers.

But given the widespread support for the specification (and my
somewhat vague memory of what led to it being created), shipping it
seems like a good thing.

Is our implementation at feature parity with those of Blink and
Edge? If not, what are the differences?

> Preference behind which this is implemented: dom.w3c_pointer_events.enabled
>
> Do other browser engines implement this?
> Edge and Chrome already ship it.
>
> Tests: WPT

The list of disabled tests in
https://bugzilla.mozilla.org/show_bug.cgi?id=1284758
seems somewhat concerning.

> Security & Privacy Concerns: none

Well, it's implemented in C++, but we don't have a better option
right now.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[stone...@gmail.com]

David Baron於 2017年4月5日星期三 UTC+8下午12時21分30秒寫道：

> The dependency trees of these bugs seem like they could use somewhat
> better organization, so that people can see what issues are
> remaining when evaluating whether enabling on nightly is
> appropriate.
>
> For example, if bug 1352278 and bug 1315189 blocked bug 1166347,
> then they and their dependencies would all show up in the dependency
> tree of bug 960316 (which presumably means enabling in all channels
> by default). (In general, if bug A needs to happen before bug B (or
> bug A needs to be uplifted in order to uplift bug B), then bug A
> should block bug B.)

Sorry for that and I'll update the dependencies.

> It seems like shipping further than nightly should also depend on
> being ready to do so on all platforms. Otherwise the Firefox
> inconsistency between platforms will be confusing for Web
> developers.

Totally agree.

> Is our implementation at feature parity with those of Blink and
> Edge? If not, what are the differences?

I think most functionalities behave the same as Blink and Edge except those spec changes in the newly closed spec issues. I plan to go through them and submit bugs for todos.

[Tom Ritter]

On Tue, Apr 4, 2017 at 10:29 PM, <stone...@gmail.com> wrote:
> Security & Privacy Concerns: none

It looks like this exposes pointerType, which reveals whether the user
is using a mouse, pen, or touch input.

It also exposes detailed information about the geometry of the input
(size of the thing pointing, pressure, tilt, twist.

All of these are more detailed information that websites currently
receiving, meaning that this can be used as a mechanism for
fingerprinting (and tracking) users.

-tom

[Aryeh Gregor]

On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter <t...@mozilla.com> wrote:
> It looks like this exposes pointerType, which reveals whether the user
> is using a mouse, pen, or touch input.
>
> It also exposes detailed information about the geometry of the input
> (size of the thing pointing, pressure, tilt, twist.
>
> All of these are more detailed information that websites currently
> receiving, meaning that this can be used as a mechanism for
> fingerprinting (and tracking) users.

I think this has been discussed here before, but I don't recall a firm
conclusion: has anyone established whether a nontrivial number of
users are non-fingerprintable as things stand? If the vast majority
of users can be fingerprinted right now, and there are no realistic
plans to change that, it doesn't seem like we should care about
increasing fingerprinting ability. I haven't investigated, but I'd be
surprised if there are a lot of users who can't be fingerprinted yet,
given the huge and rapidly-expanding number of features in the web
platform.

[Tom Ritter]

Firstly, this does not change the fact that this feature does have
Privacy implications. This is the second 'Intent to Implement' I have
replied to in the past two months that said "No Security or Privacy
Implications" when there are in fact. This trend is disturbing.

Besides that - the goal of anti-fingerprinting is not to make all
users uniform, but rather to make it harder and harder to single
individual users out. The more features we provide about users'
configuration details (like mouse pointer size, type, functionality),
the easier it is to single them out. For private browsing modes,
ideally there would be a mapping or abstraction mechanism that covers
a common denominator.

I'm not sure how much review this feature has had. In (my) ideal
world, I think when we add a feature like this, the first question we
would ask is "Why is this detailed information needed in the first
place?" and if we have a compelling answer, we would follow it up with
"Why can't we make this optional, so that it's either not exposed in
privacy preserving modes or is only exposed in ways that represent
user intention to release it?" Perhaps these questions were already
considered. But if no one thought this information was related to
Privacy to begin with, my assumption is that they were not given
serious weight.

Finally, Mozilla _is_ actively working on making users less
fingerprintable. We're devoting resources to integrating
anti-fingerprinting patches
(https://wiki.mozilla.org/Security/Fingerprinting), which is the
groundwork needed to expose the functionality to users (beyond
individual pref flags). Obviously this is tricky - it's hard to put
smoke back into bags once it's bet let out and relied upon all over
the web (which is why it's so important to adequately consider things
in Intent to X threads.). We're exploring options for this in
https://bugzilla.mozilla.org/show_bug.cgi?id=1308340 but some ideas
have been integrating with Private Browsing Mode and/or Tracking
Protection. Of course this presumes adequate research to measure
breakage, etc etc - but my point is - we're not ignoring this problem
and we do in fact care about it.

-tom

[Ehsan Akhgari]

On 2017-04-05 5:44 PM, Tom Ritter wrote:
> On Wed, Apr 5, 2017 at 12:29 PM, Aryeh Gregor <a...@aryeh.name> wrote:
>> On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter <t...@mozilla.com> wrote:
>>> It looks like this exposes pointerType, which reveals whether the user
>>> is using a mouse, pen, or touch input.
>>>
>>> It also exposes detailed information about the geometry of the input
>>> (size of the thing pointing, pressure, tilt, twist.
>>>
>>> All of these are more detailed information that websites currently
>>> receiving, meaning that this can be used as a mechanism for
>>> fingerprinting (and tracking) users.
>>
>> I think this has been discussed here before, but I don't recall a firm
>> conclusion: has anyone established whether a nontrivial number of
>> users are non-fingerprintable as things stand? If the vast majority
>> of users can be fingerprinted right now, and there are no realistic
>> plans to change that, it doesn't seem like we should care about
>> increasing fingerprinting ability. I haven't investigated, but I'd be
>> surprised if there are a lot of users who can't be fingerprinted yet,
>> given the huge and rapidly-expanding number of features in the web
>> platform.
>
> Firstly, this does not change the fact that this feature does have
> Privacy implications. This is the second 'Intent to Implement' I have
> replied to in the past two months that said "No Security or Privacy
> Implications" when there are in fact. This trend is disturbing.

This is the point of having this process. :-) Hopefully people will
start to think more about the implications of this in the future. But
see below about fingerprinting.

I agree that it would be nice to be proactive for hooking into
privacy.resistFingerprinting for features like this. And I think we
should do that for this feature specifically but of course we need to
figure out the details of what to expose instead of the real info.

But what is our official policy towards fingerprinting in Gecko in the
face of the (now public knowledge) existence of attacks such as the HSTS
super cookie? See
<https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/>
I was under the impression that given that we already expose arbitrary
number of bits through the existing features of the Web platform, this
is a lost cause. :/

In general, I should also say that designing features with
fingerprinting in mind is *extremely* difficult and takes a lot of
effort on the part of all browser vendors, which would be difficult to
do effectively without some broad agreement that the extra effort spent
is worth it. WHATWG (in HTML at least) mostly treats this by
documenting the exposed vectors
<https://html.spec.whatwg.org/multipage/introduction.html#fingerprinting-vector>.
I wonder what the position of the W3C TAG is?

(FWIW, I don't think we should hold off enabling this feature on Nightly
for this discussion, I'm excited to see it happen!)

[L. David Baron]

On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote:
> In general, I should also say that designing features with
> fingerprinting in mind is *extremely* difficult and takes a lot of
> effort on the part of all browser vendors, which would be difficult to
> do effectively without some broad agreement that the extra effort spent
> is worth it. WHATWG (in HTML at least) mostly treats this by
> documenting the exposed vectors
> <https://html.spec.whatwg.org/multipage/introduction.html#fingerprinting-vector>.
> I wonder what the position of the W3C TAG is?

That's actually a pretty easy question to answer:
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
(Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)

[mcac...@mozilla.com]

On Thursday, April 6, 2017 at 2:57:52 PM UTC+10, David Baron wrote:
> On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote:
> > In general, I should also say that designing features with
> > fingerprinting in mind is *extremely* difficult and takes a lot of
> > effort on the part of all browser vendors, which would be difficult to
> > do effectively without some broad agreement that the extra effort spent
> > is worth it. WHATWG (in HTML at least) mostly treats this by
> > documenting the exposed vectors
> > <https://html.spec.whatwg.org/multipage/introduction.html#fingerprinting-vector>.
> > I wonder what the position of the W3C TAG is?
>
> That's actually a pretty easy question to answer:
> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
> (Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)
>

There is a PR to add privacy in security considerations:
https://github.com/w3c/pointerevents/pull/193

I've pointed one of the Editors to this thread already (hopefully they will scoop up what's already been mentioned here and add it as appropriate).

People should feel free to add more comments to that pull request with their concerns.

Like any open source project, web standards are a community effort and al that :)

[Ehsan Akhgari]

On Thu, Apr 6, 2017 at 12:57 AM, L. David Baron <dba...@dbaron.org> wrote:

> On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote:
> > In general, I should also say that designing features with
> > fingerprinting in mind is *extremely* difficult and takes a lot of
> > effort on the part of all browser vendors, which would be difficult to
> > do effectively without some broad agreement that the extra effort spent
> > is worth it. WHATWG (in HTML at least) mostly treats this by
> > documenting the exposed vectors
> > <https://html.spec.whatwg.org/multipage/introduction.html#
> fingerprinting-vector>.
> > I wonder what the position of the W3C TAG is?
>
> That's actually a pretty easy question to answer:
> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
> (Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)
>

Oh, right. Thanks for the link. (Now I remember that I had read this, and
forgotten it!)

Given <
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/#limitations-of-technical-solutions>
and the previous links I posted, what _is_ Mozilla's official's policy
towards fingerprinting? In reality we do act as if we believe that it is
untenable to protect against it purely by restricting new Web features at
this point, so if this isn't our official policy it would be useful to have
that conversation explicitly. If it isn't, we shouldn't be holding people
to a higher bar than respecting privacy.resistsFingerprinting (or where we
really place that bar. :-)

Cheers,
--
Ehsan

[Eric Rescorla]

On Thu, Apr 6, 2017 at 5:26 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

I don't know if we have an official policy, but this roughly reflects my
view, with the caveat that we shouldn't add functions which have an
extremely high ratio of fingerprinting to usefulness, but I don't have
a clear test for where that line is.

-Ekr


>
> Cheers,
> --
> Ehsan
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[smaug]

On 04/05/2017 07:34 PM, Tom Ritter wrote:
> On Tue, Apr 4, 2017 at 10:29 PM, <stone...@gmail.com> wrote:
>> Security & Privacy Concerns: none
>
> It looks like this exposes pointerType, which reveals whether the user
> is using a mouse, pen, or touch input.

Note, that is already available through old moz-prefixed API (which we very much should remove)
http://searchfox.org/mozilla-central/rev/eace920a0372051a11d8d275bd9b8f14f3024ecd/dom/webidl/MouseEvent.webidl#84-92

[smaug]

On 04/05/2017 07:34 PM, Tom Ritter wrote:

> On Tue, Apr 4, 2017 at 10:29 PM, <stone...@gmail.com> wrote:
>> Security & Privacy Concerns: none
>
> It looks like this exposes pointerType, which reveals whether the user
> is using a mouse, pen, or touch input.

Note, that is already available through old moz-prefixed API (which we very much should remove)
http://searchfox.org/mozilla-central/rev/eace920a0372051a11d8d275bd9b8f14f3024ecd/dom/webidl/MouseEvent.webidl#84-92


>