Opened 5 years ago

Closed 14 months ago

Last modified 14 months ago

#10286 closed defect (fixed)

Touch events leak absolute screen coordinates

Reported by: mikeperry Owned by: arthuredelstein
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution, ff52-esr, tbb-testcase, tbb-firefox-patch, tbb-7.0-must-alpha, TorBrowserTeam201705R
Cc: gk, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description

In Firefox 24esr, Touch events are now available: https://developer.mozilla.org/en-US/docs/DOM/Touch_events. Unfortunately, these events contain absolute screen coodinates for touch event positions. We should report content-window relative coordinates for these fields.

Child Tickets

Change History (34)

comment:1 Changed 5 years ago by gk

Cc: gk added

comment:2 Changed 5 years ago by mikeperry

Keywords: ff31-esr added

Actually, it turns out Touch events were disabled for the desktop in FF24: https://bugzilla.mozilla.org/show_bug.cgi?id=888304. We have some time on this.

comment:3 Changed 5 years ago by gk

Keywords: tbb-testcase added

comment:4 Changed 4 years ago by erinn

Keywords: tbb-firefox-patch added

comment:5 Changed 4 years ago by erinn

Component: Firefox Patch IssuesTor Browser

comment:6 Changed 4 years ago by mikeperry

Keywords: ff31-esr removed

This is still not enabled in FF31. The pref is dom.w3c_touch_events.enabled. It is still 0 on my FF31 on Linux.

comment:7 Changed 4 years ago by mikeperry

Keywords: ff38-esr added

comment:8 Changed 3 years ago by mikeperry

Keywords: tbb-fingerprinting-resolution added; tbb-fingerprinting removed

comment:9 Changed 3 years ago by mikeperry

Keywords: ff45-esr added; ff38-esr removed

Still disabled in FF38.

comment:10 Changed 3 years ago by gk

Owner: set to tbb-team
Status: newassigned

comment:11 Changed 3 years ago by mcs

Cc: brade mcs added

comment:12 Changed 2 years ago by gk

Keywords: ff52-esr added; ff45-esr removed
Severity: Normal

Still off in esr45 -> esr52

comment:13 Changed 17 months ago by mcs

Sponsor: Sponsor4

It looks like TouchEvents will be enabled on Windows in ESR52 (unless something special is being done for ESR that Kathy and I missed). See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1244402

For Linux, it looks like TouchEvents were enabled in Firefox 45:
https://bugzilla.mozilla.org/show_bug.cgi?id=1217515

However, on Linux firefox must be started with MOZ_USE_XINPUT2=1 in the environment for touch support to work at all; see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1207700

comment:14 Changed 17 months ago by gk

Keywords: tbb-7.0-must added

comment:15 Changed 17 months ago by gk

Keywords: TorBrowserTeam201703 added

Getting those tickets on our March radar as well.

comment:16 Changed 17 months ago by mcs

The Touch objects that are accessible from the TouchEvents also contain "area" information including things like the radius of the area that was touched. I think that could be used for browser fingerprinting based on the size of the user's finger, how firm the touches are, etc.
See: https://developer.mozilla.org/en-US/docs/Web/API/Touch

comment:17 Changed 16 months ago by gk

Keywords: TorBrowserTeam201704 added; TorBrowserTeam201703 removed

Moving tickets over to April

comment:18 Changed 15 months ago by arthuredelstein

On the latest Tor Browser alpha, the pref "dom.w3c_touch_events.enabled" is set to 2 on Windows and Linux, which means "autodetect". Autodetect mode results in the Touch API being exposed only when touch hardware is present. So we should either set it to "1" (enable) or "0" (disable) to ensure that JS code can't fingerprint the user's hardware.

comment:19 Changed 15 months ago by gk

What do we get by setting it to "1"? I guess, it's pretty easy to find out that we are cheating in the case the underlying hardware does not support it?

comment:20 Changed 15 months ago by arthuredelstein

Owner: changed from tbb-team to arthuredelstein
Status: assignedaccepted

comment:21 Changed 15 months ago by gk

Keywords: tbb-7.0-must-alpha added; tbb-7.0-must removed

Getting more tickets on our alpha radar.

comment:22 Changed 15 months ago by arthuredelstein

Keywords: TorBrowserTeam201704R added; TorBrowserTeam201704 removed
Status: acceptedneeds_review

Here's a branch for review. There are two patches:
https://github.com/arthuredelstein/tor-browser/commits/10286

comment:23 in reply to:  22 ; Changed 15 months ago by gk

Status: needs_reviewneeds_information

Replying to arthuredelstein:

Here's a branch for review. There are two patches:
https://github.com/arthuredelstein/tor-browser/commits/10286

Could you give some motivation for this patch in light of comment:18 you raised? So, it is fine for you now to leave it in "autodetect" mode? What made you change your mind and why should we not set it to "0" for now, avoiding partitioning along touch API available/not available?

comment:24 in reply to:  23 Changed 15 months ago by arthuredelstein

Status: needs_informationneeds_review

Replying to gk:

Replying to arthuredelstein:

Here's a branch for review. There are two patches:
https://github.com/arthuredelstein/tor-browser/commits/10286

Could you give some motivation for this patch in light of comment:18 you raised? So, it is fine for you now to leave it in "autodetect" mode? What made you change your mind and why should we not set it to "0" for now, avoiding partitioning along touch API available/not available?

Sorry about that -- this was an oversight. I had meant to set the pref to "1" to prevent autodetection without having to disable the Touch API altogether. My thinking is that:

  • In the case of a tablet or phone, the platform (Android) is already detectable.
  • In the case of a laptop with a touch screen or a similar, only if the user decides to use the device is the presence of the hardware detectable. Otherwise no TouchEvents occur. So it's perhaps not a very reliable distinguisher.

So here's the new version including a patch for the pref:
https://github.com/arthuredelstein/tor-browser/commits/10286+1

If we decide we want to disable the Touch API completely instead, then of course the spoofing and test patches are potentially redundant for Tor Browser.

comment:25 Changed 15 months ago by arthuredelstein

I have thought some more and I now think my reasoning in comment:24 is wrong. Some laptop/desktop users will be using a touch screen or stylus frequently, which means that two such sessions can be positively correlated. That means we have allowed some fingerprinting, even if a third session where the Touch API is not used cannot be positively linked to the first two.

So now I am inclined to disable the Touch API altogether. Here's a new branch with 3 patches. The first simply disables the pref. The next two patches are the same as before (censoring the true screenX, etc.); the latter two are included as a possible defense in depth, in case the Touch API gets activated by the user or by us in the future, but those patches are not absolutely necessary.

https://github.com/arthuredelstein/tor-browser/commits/10286+2

comment:26 Changed 15 months ago by cypherpunks

"Disable, investigate, patch/enable" is a common formula, which you prefer to ignore again and again. There are a lot of things that can't be disabled and is waiting your attention first. Then, it's a hard task to check the "disabled" feature is really disabled, second. And only then, there's a time for investigations, which should be processed in separate tickets, IMHO.
But this ticket is about patching a new feature without investigation, huh.

comment:27 Changed 15 months ago by gk

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201704R removed

Moving review tickets to May.

comment:28 in reply to:  25 ; Changed 15 months ago by gk

Keywords: TorBrowserTeam201705 added; TorBrowserTeam201705R removed
Status: needs_reviewneeds_revision

Replying to arthuredelstein:

I have thought some more and I now think my reasoning in comment:24 is wrong. Some laptop/desktop users will be using a touch screen or stylus frequently, which means that two such sessions can be positively correlated. That means we have allowed some fingerprinting, even if a third session where the Touch API is not used cannot be positively linked to the first two.

So now I am inclined to disable the Touch API altogether. Here's a new branch with 3 patches. The first simply disables the pref. The next two patches are the same as before (censoring the true screenX, etc.); the latter two are included as a possible defense in depth, in case the Touch API gets activated by the user or by us in the future, but those patches are not absolutely necessary.

https://github.com/arthuredelstein/tor-browser/commits/10286+2

I think the approach is okay for now. We might want to think harder whether we want to enable touch support in the future by default and rely only on the spoofing.

Arthur: Did you run the test? It seems it passes/fails depending on the platform which seems suboptimal. If that's the case can you fix that? Then there is a typo: 100286 (we don't have 6-digit bug numbers yet). I got confused by the pointer event references, in particular https://bugzilla.mozilla.org/show_bug.cgi?id=1000870 in the test. Is that the way to write tests for touch event related things?

FWIW: I did not compile the code yet nor did I run a Tor Browser with the patches.

comment:29 in reply to:  28 Changed 15 months ago by arthuredelstein

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201705 removed
Status: needs_revisionneeds_review

Replying to gk:

I think the approach is okay for now. We might want to think harder whether we want to enable touch support in the future by default and rely only on the spoofing.

Arthur: Did you run the test? It seems it passes/fails depending on the platform which seems suboptimal. If that's the case can you fix that?

I ran the test on a Linux box with no touch screen. I expect the test to pass on every platform, because the TouchEvent is synthetic (not dependent on hardware).

Then there is a typo: 100286 (we don't have 6-digit bug numbers yet). I got confused by the pointer event references, in particular https://bugzilla.mozilla.org/show_bug.cgi?id=1000870 in the test. Is that the way to write tests for touch event related things?

Sorry, I left these in inadvertently. I removed the last references to pointer events and fixed the typo and link. I also did some extra cleanup.

Here's the new version (3 patches as before):
https://github.com/arthuredelstein/tor-browser/commits/10286+3

comment:30 Changed 14 months ago by gk

This looks good to me.

comment:31 Changed 14 months ago by mcs

I reviewed the patches and they look okay. But for some reason when I run the tests on OSX two of them fail:

6 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_touchevent_resist_fingerprinting.html | touch.radiusX - got 4, expected 2
7 INFO TEST-UNEXPECTED-FAIL | dom/events/test/test_touchevent_resist_fingerprinting.html | touch.radiusY - got 6, expected 3

I am not yet sure why the failures are occuring. Unfortunately I am out of time for now, but I will try to investigate more later tonight or early tomorrow.

comment:32 in reply to:  31 ; Changed 14 months ago by mcs

Replying to mcs:

I am not yet sure why the failures are occuring. Unfortunately I am out of time for now, but I will try to investigate more later tonight or early tomorrow.

The test failures occurred in the "fingerprinting resistance off" case. Kathy came up with a good theory: maybe the doubling of the radius occurred because I ran the tests on a Mac with a Retina (2x) display. If that is what is happening, this seems like a Firefox bug (maybe in the test code that synthesizes events?) since all distance units within the Touch Events are supposed to be CSS pixels. This should not prevent us from merging these patches.

comment:33 in reply to:  32 ; Changed 14 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to mcs:

Replying to mcs:

I am not yet sure why the failures are occuring. Unfortunately I am out of time for now, but I will try to investigate more later tonight or early tomorrow.

The test failures occurred in the "fingerprinting resistance off" case. Kathy came up with a good theory: maybe the doubling of the radius occurred because I ran the tests on a Mac with a Retina (2x) display. If that is what is happening, this seems like a Firefox bug (maybe in the test code that synthesizes events?) since all distance units within the Touch Events are supposed to be CSS pixels. This should not prevent us from merging these patches.

Good theory. Do you mind filing an upstream bug for that? Meanwhile, I applied the patches to tor-browser-52.1.0esr-7.0-2 (commits 1b6559c0763f2ae0c9ad56307642e6d6462c3ede, 331f089d6b6ba62463d8362d7ca01641a4cc92dc, and 00d2bfb5067659c352690c06cb85a8b76bc7addb).

comment:34 in reply to:  33 Changed 14 months ago by mcs

Replying to gk:

Good theory. Do you mind filing an upstream bug for that? Meanwhile, I applied the patches to tor-browser-52.1.0esr-7.0-2 (commits 1b6559c0763f2ae0c9ad56307642e6d6462c3ede, 331f089d6b6ba62463d8362d7ca01641a4cc92dc, and 00d2bfb5067659c352690c06cb85a8b76bc7addb).

Kathy and I confirmed that the problem does not occur on an older non-Retina MacBook Pro, and then I created https://bugzilla.mozilla.org/show_bug.cgi?id=1364969

Note: See TracTickets for help on using tickets.