Bug 1980472 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

After Bug 1957658 we now have with RFP and maxTouchPoints (correct me I'm wrong, thanks - Tor Browser I assume will backport or ask for a backport)
- android: `5`
- windows: `10`
- mac + linux: `0`

There is also a pref, `dom.w3c_touch_events.enabled`  `0`=disabled (macOS) `1`=enabled `2`=autodetect (linux/win/android) - I think the prefs are as I've just written, the notes are from a year ago. Android is fine (always has touch), mac is fine (no such thing, yet)

With autodetect: on android this adds a number of `ontouch*` properties (window, element), but not desktop, as these properties cause compat issues with websites arbitrarily deciding this means you are mobile. But the other thing this does, is also add some element `Touch*` properties, which are fingerprintable. So with windows, my touch capable laptop has these values, but my non-touch desktop rig doesn't - and reporting 10 maxTouchPoints without those properties is a mismatch, not to mention we are creating entropy that doesn't need to exist. For linux I am not sure what happens - IIUIC touch requires a startup command - but it shouldn't matter since we can control it all.

The pref can be toggled and does not require a restart, so it should work with RFPTargets and exemptions.

Here's a code snippet
```js
let rfpHashes = {
	'android': 'c8ec70b1',
		/*
		{	"element": ["ontouchstart", "ontouchend", "ontouchmove", "ontouchcancel"],
			"maxTouchPoints": 5,
			"window": ["TouchEvent","TouchList","Touch","ontouchstart","ontouchend","ontouchmove","ontouchcancel"]
		}
		*/
	'linux': 'd539fa63', // {"element": "none", "maxTouchPoints": 0, "window": "none"}
	'mac': 'd539fa63',
	'windows': '14bcf9db', // {"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}
}
```

These are real-world benign values that don't break expected gecko behavior.

### ToDo
- windows: enforce `dom.w3c_touch_events.enabled` as `1`
- linux: enforce `dom.w3c_touch_events.enabled` as `0`
- Tor Browser can just enforce these prefs since they don't use RFPTargets
After Bug 1957658 we now have with RFP and maxTouchPoints (correct me I'm wrong, thanks - Tor Browser I assume will backport or ask for a backport)
- android: `5`
- windows: `10`
- mac + linux: `0`

There is also a pref, `dom.w3c_touch_events.enabled`  `0`=disabled (macOS) `1`=enabled `2`=autodetect (linux/win/android) - I think the prefs are as I've just written, the notes are from a year ago. Android is fine (always has touch), mac is fine (no such thing, yet)

With autodetect: on android this adds a number of `ontouch*` properties (window, element), but not desktop, as these properties cause compat issues with websites arbitrarily deciding this means you are mobile. But the other thing this does, is also add some element `Touch*` properties, which are fingerprintable. So with windows, my touch capable laptop has these values, but my non-touch desktop rig doesn't - and reporting 10 maxTouchPoints without those properties is a mismatch, not to mention we are creating entropy that doesn't need to exist. For linux I am not sure what happens - IIUIC touch requires a startup command - but it shouldn't matter since we can control it all.

The pref can be toggled and does not require a restart, so it should work with RFPTargets and exemptions.

Here's a code snippet (**edit: the hashes are what I would expect when we fix this**)
```js
let rfpHashes = {
	'android': 'c8ec70b1',
		/*
		{	"element": ["ontouchstart", "ontouchend", "ontouchmove", "ontouchcancel"],
			"maxTouchPoints": 5,
			"window": ["TouchEvent","TouchList","Touch","ontouchstart","ontouchend","ontouchmove","ontouchcancel"]
		}
		*/
	'linux': 'd539fa63', // {"element": "none", "maxTouchPoints": 0, "window": "none"}
	'mac': 'd539fa63',
	'windows': '14bcf9db', // {"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}
}
```

These are real-world benign values that don't break expected gecko behavior.

### ToDo
- windows: enforce `dom.w3c_touch_events.enabled` as `1`
- linux: enforce `dom.w3c_touch_events.enabled` as `0`
- Tor Browser can just enforce these prefs since they don't use RFPTargets
After Bug 1957658 we now have with RFP and maxTouchPoints (correct me I'm wrong, thanks - Tor Browser I assume will backport or ask for a backport)
- android: `5`
- windows: `10`
- mac + linux: `0`

There is also a pref, `dom.w3c_touch_events.enabled`  `0`=disabled (macOS) `1`=enabled `2`=autodetect (linux/win/android) - I think the prefs are as I've just written, the notes are from a year ago. Android is fine (always has touch), mac is fine (no such thing, yet)

With autodetect: on android this adds a number of `ontouch*` properties (window, element), but not desktop, as these properties cause compat issues with websites arbitrarily deciding this means you are mobile. But the other thing this does, is also add some ~~element~~ window `Touch*` properties, which are fingerprintable. So with windows, my touch capable laptop has these values, but my non-touch desktop rig doesn't - and reporting 10 maxTouchPoints without those properties is a mismatch, not to mention we are creating entropy that doesn't need to exist. For linux I am not sure what happens - IIUIC touch requires a startup command - but it shouldn't matter since we can control it all.

The pref can be toggled and does not require a restart, so it should work with RFPTargets and exemptions.

Here's a code snippet (**edit: the hashes are what I would expect when we fix this**)
```js
let rfpHashes = {
	'android': 'c8ec70b1',
		/*
		{	"element": ["ontouchstart", "ontouchend", "ontouchmove", "ontouchcancel"],
			"maxTouchPoints": 5,
			"window": ["TouchEvent","TouchList","Touch","ontouchstart","ontouchend","ontouchmove","ontouchcancel"]
		}
		*/
	'linux': 'd539fa63', // {"element": "none", "maxTouchPoints": 0, "window": "none"}
	'mac': 'd539fa63',
	'windows': '14bcf9db', // {"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}
}
```

These are real-world benign values that don't break expected gecko behavior.

### ToDo
- windows: enforce `dom.w3c_touch_events.enabled` as `1`
- linux: enforce `dom.w3c_touch_events.enabled` as `0`
- Tor Browser can just enforce these prefs since they don't use RFPTargets

Back to Bug 1980472 Comment 0