Consider how to do Anti-fingerprinting for Pointer Events

RESOLVED FIXED in Firefox 64

Status

()

enhancement
P1
normal
RESOLVED FIXED
2 years ago
7 months ago

People

(Reporter: tjr, Assigned: timhuang)

Tracking

(Depends on 1 bug, Blocks 1 bug)

unspecified
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

(Whiteboard: [tor 25794][fingerprinting])

Attachments

(4 attachments)

Reporter

Description

2 years ago
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.
Reporter

Comment 1

2 years ago
Hsinyi, do you think you can answer my question about "with Pointer Events turned off, what happens if you use pointer?"
Flags: needinfo?(htsai)
Reporter

Comment 2

2 years ago
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.
Flags: needinfo?(arthuredelstein)
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.
Flags: needinfo?(arthuredelstein)
Why would you want to disable pointer events in case they are dispatched based on mouse events?
Reporter

Comment 5

2 years ago
(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?
The hope is that in the long run web pages move away from mouse and touch events and use just pointer events.
(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.
Flags: needinfo?(htsai)
Priority: -- → P2
Reporter

Comment 8

2 years ago
(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.
(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?
(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?  :)
Flags: needinfo?(tihuang)
(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?
Flags: needinfo?(dveditz)
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.
Flags: needinfo?(tihuang)
Reporter

Comment 13

2 years ago
(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 =)
Flags: needinfo?(dveditz)
(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.
Priority: P2 → P3
Pointer Event will be shipped in FF 58.
We need to fix this bug in FF59.
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp:backlog]
Priority: P3 → P2
Whiteboard: [tor][fingerprinting][fp:backlog] → [tor 25794][fingerprinting]
Assignee

Comment 16

9 months ago
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.
Assignee

Updated

9 months ago
Assignee: nobody → tihuang
Assignee

Comment 17

8 months ago
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.
Assignee

Comment 18

8 months ago
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
Assignee

Comment 19

8 months ago
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
Assignee

Comment 20

8 months ago
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 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.
Attachment #9009556 - Flags: review+
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.
Attachment #9009558 - Flags: review+
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.
Attachment #9009556 - Flags: review+
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.
Attachment #9009557 - Flags: review+
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.
Attachment #9009558 - Flags: review+
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.
Attachment #9009559 - Flags: review+
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.
Attachment #9009556 - Flags: review+
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.
Attachment #9009558 - Flags: review+
Assignee

Updated

8 months ago
Depends on: 1492766
Assignee

Updated

8 months ago
Depends on: 1492775
Reporter

Updated

8 months ago
Priority: P2 → P1
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.
Attachment #9009557 - Flags: review+

Comment 31

7 months ago
Pushed by tihuang@mozilla.com:
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
You need to log in before you can comment on or make changes to this bug.