1363508 - Consider how to do Anti-fingerprinting for Pointer Events

Status: RESOLVED FIXED

(Core :: DOM: Events, enhancement, P1)

Description

[Tom Ritter [:tjr]]

We had begun a conversation in email about how we can handle the fingerprinting concerns with Pointer Events.  Consider:
 - https://groups.google.com/d/msg/mozilla.dev.platform/ssgPuYOIwwc/7HFCFuQeDQAJ
 - https://github.com/w3c/pointerevents/pull/193

I think there's multiple things at play here:

1) We should be able to disable the feature altogether with some sort of preference.

2) We'd like to have Telemetry about the feature to see if anyone uses it

3) We _may_ want to keep the feature *enabled*, but reduce its ability to fingerprint a user. But, first, let me ask: with Pointer Events turned off, what happens if you use pointer? Does it behave as a mouse click? If so, the following suggestion is probably unneeded, but if just nothing happens at all, then we'd probably like to keep some functionality but reduce the fingerprinting ability.

We could do this by hardcoding _all_ aspects of the PointerEvent class. What a webpage would be left with the ability to tell when (and where) a user has pointed, but nothing additional about the user such as characteristics of the pointing device. 

This could be something we do when privacy.ResistFingerprinting is turned on.

4) Because PointerEvent inherits from MouseEvent, we need to make sure that .screenX and .screenY get spoofed as .clientX and .clientY when privacy.ResistFingerprinting is turned on.

Comment 1

[Tom Ritter [:tjr]]

Hsinyi, do you think you can answer my question about "with Pointer Events turned off, what happens if you use pointer?"

Comment 2

[Tom Ritter [:tjr]]

And tagging Arthur to make sure he sees it and to ask if my representation of (4) is correct and sufficient, as we definitely need #4 (and #1 and ideally #2) to happen.

Comment 3

[Arthur Edelstein [:arthur]]

One nit is that it is "privacy.resistFingerprinting" with lowercase r. :)

But this all sounds good to me. I very recently wrote very similar patches for Touch Events. (I hope these will land soon in Tor Browser and will be uplifted to Firefox.) The patches include disabling Touch Events by a pref, and also hardcoding various TouchEvent members, and finally spoofing .screenX/Y as .clientX/Y. Here they are, in case it's useful for comparison:
https://github.com/arthuredelstein/tor-browser/commits/10286+3

Looks like pointer events can be disabled by setting "dom.w3c_pointer_events.enabled" to false. So one option would be to bind this pref to privacy.resistFingerprinting, as in bug 1333933.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Why would you want to disable pointer events in case they are dispatched based on mouse events?

Comment 5

[Tom Ritter [:tjr]]

(In reply to Olli Pettay [:smaug] from comment #4)
> Why would you want to disable pointer events in case they are dispatched
> based on mouse events?

If Pointer Events is disabled but the browser sends Mouse Events in their place, then we could turn off the API and eliminate the fingerprinting properties of the API without significantly hurting browser functionality. Sure, fancy image editing apps that would rely on the nuances of a stylus movement wouldn't work, but if a user is trying to click on DOM element, that would still work. Am I thinking about it right?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

The hope is that in the long run web pages move away from mouse and touch events and use just pointer events.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Tom Ritter [:tjr] from comment #1)
> Hsinyi, do you think you can answer my question about "with Pointer Events
> turned off, what happens if you use pointer?"

Yes, I do. Basically as you said, it behaves as mouse click. To be more specifically, the browser sends Mouse Events for pen and Touch events for touch with Pointer events disabled.

That said, as Olli commented, considering the long term hope/plan (and the reason why Pointer events was designed), I think we'd take care of the situation that turning off Pointer Events will cause nothing happening at all eventually. Thus, keeping some functionality but reduce the fingerprinting ability would be the most sensible direction to me.

Comment 8

[Tom Ritter [:tjr]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> (In reply to Tom Ritter [:tjr] from comment #1)
> > Hsinyi, do you think you can answer my question about "with Pointer Events
> > turned off, what happens if you use pointer?"
> 
> Yes, I do. Basically as you said, it behaves as mouse click. To be more
> specifically, the browser sends Mouse Events for pen and Touch events for
> touch with Pointer events disabled.
> 
> That said, as Olli commented, considering the long term hope/plan (and the
> reason why Pointer events was designed), I think we'd take care of the
> situation that turning off Pointer Events will cause nothing happening at
> all eventually. Thus, keeping some functionality but reduce the
> fingerprinting ability would be the most sensible direction to me.

That sounds good to me.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Tom Ritter [:tjr] from comment #8)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> > (In reply to Tom Ritter [:tjr] from comment #1)
> > > Hsinyi, do you think you can answer my question about "with Pointer Events
> > > turned off, what happens if you use pointer?"
> > 
> > Yes, I do. Basically as you said, it behaves as mouse click. To be more
> > specifically, the browser sends Mouse Events for pen and Touch events for
> > touch with Pointer events disabled.
> > 
> > That said, as Olli commented, considering the long term hope/plan (and the
> > reason why Pointer events was designed), I think we'd take care of the
> > situation that turning off Pointer Events will cause nothing happening at
> > all eventually. Thus, keeping some functionality but reduce the
> > fingerprinting ability would be the most sensible direction to me.
> 
> That sounds good to me.

Cool, then we go with the solution that spoof certain attributes when privacy.resistFingerprinting is turned on, right?

One more question is about how the spoofing blocks this Pointer Events feature.
a) Blocking enabling PE on linux & MAC on Nightly only? ==> I personally don't think so, as it's not really shipped. Also, PE has been enabled on Windows Nightly for a while.
b) Should we fix the spoofing before shipping PE to all desktop platforms on release? Comments?

Comment 10

[Ethan Tseng [:ethan]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> Cool, then we go with the solution that spoof certain attributes when
> privacy.resistFingerprinting is turned on, right?
 
Yes.

Whoever working on this bug should syn up with Tim Huang for the solution.
Tim has implemented the nsRFPService (Resist Fingerprinting service) which is used to observe the change of the pref 'privacy.resistfingerprinting' in bug 1330890.
Also, he's designing a way to make the anti-fingeprinting solutions in different components more easily and consistent.
Tim, maybe you could share more detail about this?  :)

Comment 11

[Ethan Tseng [:ethan]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> One more question is about how the spoofing blocks this Pointer Events
> feature.
> a) Blocking enabling PE on linux & MAC on Nightly only? ==> I personally
> don't think so, as it's not really shipped. Also, PE has been enabled on
> Windows Nightly for a while.
> b) Should we fix the spoofing before shipping PE to all desktop platforms on
> release? Comments?

Dan, could you give an advice for this question?
Or do you know who would be the best person to consult with?

Comment 12

[Tim Huang[:timhuang]]

What I am working on is that using nsRFPService to flip prefs automatically whenever 'privacy.resistFingerprinting' is changed. So, the nsRFPServie will maintain a list of prefs and their values for fingerprinting resistance. When 'privacy.resistFingerprinting' is turned on, the nsRFPService will store original values and set these prefs properly. When we disable fingerprinting resistance, the service will restore the original values.

If the feature can be spoofed or disabled by preferences, then we don't have to intentionally add nsContentUtils::ShouldResistFingerprinting() everywhere. The nsRFPService can take care of this job. In addition, it provides a convenient way to add more anti-fingerprinting prefs in the future.

Comment 13

[Tom Ritter [:tjr]]

(In reply to Ethan Tseng [:ethan] from comment #11)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> > One more question is about how the spoofing blocks this Pointer Events
> > feature.
> > a) Blocking enabling PE on linux & MAC on Nightly only? ==> I personally
> > don't think so, as it's not really shipped. Also, PE has been enabled on
> > Windows Nightly for a while.
> > b) Should we fix the spoofing before shipping PE to all desktop platforms on
> > release? Comments?
> 
> Dan, could you give an advice for this question?
> Or do you know who would be the best person to consult with?

I'll answer for him. We don't need to block PE in any situation (a or b) on the anti-fingerprinting/spoofing behavior. We must get it fixed by FF 59, but before that we don't have any concrete plans to make use of the anti-fingerprinting behavior. (I hope that will change, and then maybe this will get bumped up in priority, but when that happens it can re-prioritize then.)



Regarding the pref service, because of the way it works and our goal with spoofing, there are two options:

1) Ignore the pref service, and use nsContentUtils::ShouldResistFingerprinting() to determine if we spoof parts of the results

2) Create a new preference: dom.pointerevents.resistFingerprinting - and when that is enabled, spoof parts of the results. The pref service Tim is working on will then read and write that value.  (This is in addition to the dom.pointerevents.enabled pref we should have to turn it on and off entirely.)  

#2 is a layer of abstraction that makes things slightly more flexible, but I'm not sure that flexibility is actually needed. Would anyone say "I don't want to turn on _all_ of Resist Fingerprinting, but I do want to adjust the pointer events!" Seems unlikely.

However, it may be the case that someone says "I do want to turn on all of Resist Fingerprinting, but after I do it, I want to turn off the pointer events spoofing because I happen to do some image editing in Firefox and pointer events lets me use my stylus well."  

I lean towards #2, but I always lean towards more complexity, so I leave it up to someone else to decide =)

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Tom Ritter [:tjr] from comment #13)
> (In reply to Ethan Tseng [:ethan] from comment #11)
> > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)
> > > One more question is about how the spoofing blocks this Pointer Events
> > > feature.
> > > a) Blocking enabling PE on linux & MAC on Nightly only? ==> I personally
> > > don't think so, as it's not really shipped. Also, PE has been enabled on
> > > Windows Nightly for a while.
> > > b) Should we fix the spoofing before shipping PE to all desktop platforms on
> > > release? Comments?
> > 
> > Dan, could you give an advice for this question?
> > Or do you know who would be the best person to consult with?
> 
> I'll answer for him. We don't need to block PE in any situation (a or b) on
> the anti-fingerprinting/spoofing behavior. We must get it fixed by FF 59,
> but before that we don't have any concrete plans to make use of the
> anti-fingerprinting behavior. (I hope that will change, and then maybe this
> will get bumped up in priority, but when that happens it can re-prioritize
> then.)
> 
All clear to me, thanks Tom.

Comment 15

[Ethan Tseng [:ethan]]

Pointer Event will be shipped in FF 58.
We need to fix this bug in FF59.

Comment 16

[Tim Huang[:timhuang]]

Per offline discussion, we would like to protect pointer events from fingerprinting resistance by spoofing "pen" and "touch" pointer events into "mouse" pointer events. By doing so, the basic functionality of pointer events would still be preserved. However, this would break some contents that are built for "touch" and "pen", like a multi-touch scenario. For this case, we are also thinking that we might be able to add a permission for fingerprinting resistance which allows users to opt-out fingerprinting protection per origin, but I think this is beyond the scope of this bug.

Comment 17

[Tim Huang[:timhuang]]

Attachment: Bug 1363508 - Part 1: Spoofing pen/touch pointer events into mouse pointer events when fingerprinting resistance is on

The pointerType field in the pointer event will reveal the details of
users' hardware; this is a fingerprinting vector. So, we would spoof all
types of pointer events into mouse type pointer events for protecting
users from browser fingerprinting when fingerprinting resistance is on.

In this patch, we would spoof the pointerType as well as other fields
that mouse pointer events don't support, like pressure, tiltX/Y and so
on when fingerprinting resistance is on.

Comment 18

[Tim Huang[:timhuang]]

Attachment: Bug 1363508 - Part 2: Suppressing the pointer events that have isPrimary as false for fingerprinting resistance

Because of that the isPrimary of mouse pointer events will alwasy be
true. So, we suppress other events that have isPrimary as false when
fingerprinting resistance is enabled.

Depends on D6003

Comment 19

[Tim Huang[:timhuang]]

Attachment: Bug 1363508 - Part 3: Spoofing navigator.maxTouchPoints into 0 if fingerprinting resistance is enabled

The maxTouchPoints is going to review the detail of users' hardware. So,
we will spoof it into 0 if fingerprinting resistance is on.

Depends on D6004

Comment 20

[Tim Huang[:timhuang]]

Attachment: Bug 1363508 - Part 4: Add a test case for testing pointer event spoofing when fingerprinting resistance is on

This patch add a mochitest which tests all pointer events to assure
touch and pen pointer events will be spoofed into mouse pointer events.
However, we are not able to test the suppressing of the non-primary
pointer events since we cannot generate a pointer event with isPrimary
as false so far.

Depends on D6005

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9009556 [details]
Bug 1363508 - Part 1: Spoofing pen/touch pointer events into mouse pointer events when fingerprinting resistance is on

Olli Pettay [:smaug] has approved the revision.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 9009558 [details]
Bug 1363508 - Part 3: Spoofing navigator.maxTouchPoints into 0 if fingerprinting resistance is enabled

Olli Pettay [:smaug] has approved the revision.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 9009556 [details]
Bug 1363508 - Part 1: Spoofing pen/touch pointer events into mouse pointer events when fingerprinting resistance is on

Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) has approved the revision.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 9009557 [details]
Bug 1363508 - Part 2: Suppressing the pointer events that have isPrimary as false for fingerprinting resistance

Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) has approved the revision.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 9009558 [details]
Bug 1363508 - Part 3: Spoofing navigator.maxTouchPoints into 0 if fingerprinting resistance is enabled

Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) has approved the revision.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 9009559 [details]
Bug 1363508 - Part 4: Add a test case for testing pointer event spoofing when fingerprinting resistance is on

Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) has approved the revision.

Comment 27

[Arthur Edelstein [:arthur]]

Comment on attachment 9009556 [details]
Bug 1363508 - Part 1: Spoofing pen/touch pointer events into mouse pointer events when fingerprinting resistance is on

Arthur Edelstein (Tor Browser dev) [:arthuredelstein] has approved the revision.

Comment 28

[Arthur Edelstein [:arthur]]

Comment on attachment 9009558 [details]
Bug 1363508 - Part 3: Spoofing navigator.maxTouchPoints into 0 if fingerprinting resistance is enabled

Arthur Edelstein (Tor Browser dev) [:arthuredelstein] has approved the revision.

Comment 29

[Arthur Edelstein [:arthur]]

Comment on attachment 9009557 [details]
Bug 1363508 - Part 2: Suppressing the pointer events that have isPrimary as false for fingerprinting resistance

Arthur Edelstein (Tor Browser dev) [:arthuredelstein] has approved the revision.

Comment 30

[Tim Huang[:timhuang]]

Try looks good.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=31bd0f2f87ce98d8eeb4d1cd34f5e11df4c22d09

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e9933f36e45
Part 1: Spoofing pen/touch pointer events into mouse pointer events when fingerprinting resistance is on r=arthuredelstein,masayuki,smaug
https://hg.mozilla.org/integration/autoland/rev/24afd8e04316
Part 2: Suppressing the pointer events that have isPrimary as false for fingerprinting resistance r=arthuredelstein,masayuki
https://hg.mozilla.org/integration/autoland/rev/d56cf859abf7
Part 3: Spoofing navigator.maxTouchPoints into 0 if fingerprinting resistance is enabled r=arthuredelstein,masayuki,smaug
https://hg.mozilla.org/integration/autoland/rev/7741c70c8bce
Part 4: Add a test case for testing pointer event spoofing when fingerprinting resistance is on r=arthuredelstein,masayuki

Comment 32

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/3e9933f36e45
https://hg.mozilla.org/mozilla-central/rev/24afd8e04316
https://hg.mozilla.org/mozilla-central/rev/d56cf859abf7
https://hg.mozilla.org/mozilla-central/rev/7741c70c8bce