Touch events leak absolute screen coordinates

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.

added TorBrowserTeam201705R component::applications/tor browser ff52-esr owner::arthuredelstein priority::high resolution::fixed severity::normal sponsor::4 status::closed tbb-7.0-must-alpha tbb-fingerprinting-resolution tbb-firefox-patch tbb-testcase type::defect labels

Trac:
Cc: N/A to gk

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.

Trac:
Keywords: N/A deleted, ff31-esr added

Trac:
Keywords: N/A deleted, tbb-testcase added

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser

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

Trac:
Keywords: ff31-esr deleted, N/A added

Trac:
Keywords: N/A deleted, ff38-esr added

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-resolution added

Still disabled in FF38.

Trac:
Keywords: ff38-esr deleted, ff45-esr added

Trac:
Owner: N/A to tbb-team
Status: new to assigned

Trac:
Cc: gk to gk, brade, mcs

Still off in esr45 -> esr52

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Keywords: ff45-esr deleted, ff52-esr added
Reviewer: N/A to N/A

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

Trac:
Sponsor: N/A to Sponsor4

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Getting those tickets on our March radar as well.

Trac:
Keywords: N/A deleted, TorBrowserTeam201703 added

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

Moving tickets over to April

Trac:
Keywords: TorBrowserTeam201703 deleted, TorBrowserTeam201704 added

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.

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?

Trac:
Owner: tbb-team to arthuredelstein
Status: assigned to accepted

Getting more tickets on our alpha radar.

Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added

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

Trac:
Status: accepted to needs_review
Keywords: TorBrowserTeam201704 deleted, TorBrowserTeam201704R added

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?

Trac:
Status: needs_review to needs_information

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.

Trac:
Status: needs_information to needs_review

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

"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.

Moving review tickets to May.

Trac:
Keywords: TorBrowserTeam201704R deleted, TorBrowserTeam201705R added

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.

Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201705R deleted, TorBrowserTeam201705 added

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

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added

This looks good to me.

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.

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.

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).

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

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

closed

mentioned in issue #16337 (moved)

mentioned in issue #19048 (moved)

mentioned in issue #28535 (moved)

moved to tpo/applications/tor-browser#10286 (closed)

mentioned in issue tpo/applications/tor-browser#28535

mentioned in issue tpo/applications/tor-browser#41373