are timestamps a potential tracking/fingerprinting vector?

[samuelweiler]

Could high resolution timestamps provided by the gamepad to multiple sites be a fingerprinting vector?

Would it be possible, instead of using an absolute time for navigationStart, to instead use a random value that changes with each browsing context? That way timestamps given to two sites using the gamepad cannot be usefully compared.

[domenic]

It would be quite strange to make gamepad timestamps different from all other timestamps on the platform. For example, via the timeStamp property, every DOM event is already given relative to navigation start: https://dom.spec.whatwg.org/#ref-for-dom-event-timestamp%E2%91%A1

[reillyeon]

A gamepad event can be delivered to multiple browsing contexts (not just the focused context) and thus leaks information cross-origin in a way that other APIs do not.

[dontcallmedom]

is there any reason it is not limited to the focused context? that's the approach taken by the generic sensor API: https://www.w3.org/TR/generic-sensor/#focused-area

[reillyeon]

Chrome has a page visibility check however I don't see any references to this in the specification. I have mixed feelings on whether or not we should deliver events to an unfocused page. On the one hand it is positive for privacy however since users often are not using a mouse or keyboard while using a gamepad this means that if focus is stolen from their gaming session they lose all control of it and so it isn't a great user experience.

[domenic]

I guess I'm just unclear why gamepad input would be different from mouse or keyboard input (especially keyboard input) in this sense.

It does sound like there's a potential interop issue here that perhaps deserves its own issue.

[reillyeon]

Chatted offline with @samuelweiler and we decided that the language in the spec was a convoluted way of saying that timestamp starts at 0 when the navigation is started. We agreed that this is not likely a vector for fingerprinting as each frame has a different zero-point.

The question of events delivered to multiple browsing contexts is a separate issue. Given that this is a polling as well as event-driven interface we should consider both whether connect/disconnect events (as well as future button/axis events) are fired for a visible, but not foreground, frame and whether a page polling navigator.gamepads in the background observes changes.

[garykac]

AIUI, the gamepad is not really associated with a window or an element, but rather with the entire display/desktop. The gamepad differs from keyboard/mouse in that it doesn't change (or respect) the focused element (see Reilly's pop-up example).

Given that, I think that it makes sense for the gamepad api to be available to the current tab in all visible windows. But it should not be available to tabs/elements/windows that are not visible or in the background.

In any case, I'm having trouble convincing myself that there's a big fingerprinting concern. If I understand correctly, the attack requires that the user:

• Open multiple window from same (or related origin)
• Interact with both of these windows with the gamepad API

And then the attack gets the delta between these 2 windows' session creation time. It doesn't seem like this allows tracking across user sessions since this delta will differ.

For fingerprinting, I'm more worried about the "drive-by" web where the user doesn't interact with the page and doesn't have any indications that something's going on. In this case, the user has to interact and the site has to either trick the user into opening 2 windows, or popup secondary windows. So this doesn't seem to rise to the level where we need to jump through hoops to avoid.

More concerning is that I didn't see a place in the spec where the API was restricted to something like the top-level browsing context of currently visible windows. Having this API available to hidden or background tabs is more of a fingerprinting/privacy concern to me than the multiple window attack scenario.

[luser]

For fingerprinting, I'm more worried about the "drive-by" web where the user doesn't interact with the page and doesn't have any indications that something's going on.

I think the spec covers fingerprinting concerns reasonably well since it requires interaction with a gamepad while the page is visible.

More concerning is that I didn't see a place in the spec where the API was restricted to something like the top-level browsing context of currently visible windows.

The intention has always been that updated data would only be available to visible windows, but it doesn't seem like that ever made it into the spec text. It sounds like Chrome implements this, and Firefox definitely does, I wrote a test for that behavior a long time ago:
https://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/gamepad/test_gamepad_frame_state_sync_iframe.html

In regards to only making it available to top-level browsing contexts I'm less sure. I don't know that it would explicitly break current uses, but being unable to use a gamepad because a site has embedded a game in an iframe would be unfortunate, certainly.

[samuelweiler]

@reillyeon writes:

The question of events delivered to multiple browsing contexts is a separate issue. Given that this is a polling as well as event-driven interface we should consider both whether connect/disconnect events (as well as future button/axis events) are fired for a visible, but not foreground, frame and whether a page polling navigator.gamepads in the background observes changes.

This issue, and I acknowledge that it is separate, is coming up in discussions of other specs, include the base HTML. Some pointers to the discussion can be found at: w3cping/tracking-issues#34