Extending the PointerEvent with Unique DeviceId Attribute

[bmathwig]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Extending the PointerEvent with Unique DeviceId Attribute
• Specification or proposal URL: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Introduction

Devices are now shipping with advanced pen input capabilities such as the ability for a digitizer to recognize two unique pen devices simultaneously providing input. This proposal explores adding a new deviceId attribute to PointerEvent in order to safely provide developers with persistent unique identifiers for their inking applications.

Problems with Current Solutions

Currently, the pointerId attribute on PointerEvent does not mandate a persistent identifier for a device and often will cycle the identifier for each new event received. In addition, if we were to use pointerId as a fixed value for pen devices that do support fetching a unique hardware ID, how would we handle devices that do not? The pointerId attribute would not be deterministic in this case and older pen devices would present themselves as new devices for each stroke.

Proposed Solution

The proposed solution is to add a new attribute deviceId to PointerEvent that has the following characteristics:

• The attribute will be populated if both the digitizer and the pen support getting a unique hardware ID for the pen.
• The attribute will be null if the digitizer and pen support getting a unique hardware ID, but the ID is not available during the current event due to limitations (see Limitations of Current Hardware).
• The attribute will be undefined if either the digitizer or the pen do not support getting a unique hardware ID.

Privacy

To address privacy concerns about fingerprinting, we propose not exposing the hardware serial number to the developer, but instead a randomly generated ID that is persistent for the life of the document and is regenerated during a new browsing session. The same pane in the same browser session across two different documents will not have the same ID.

IDL

partial interface PointerEvent {
    readonly attribute unsigned long? deviceId;
}

[sahirv]

The shape of this API has changed. It now takes the following form:

partial interface PointerEvent {
    readonly attribute DeviceProperties? deviceProperties;
}

interface DeviceProperties {
    constructor(optional DevicePropertiesInit devicePropertiesInitDict = {});
    readonly attribute long uniqueId;
}

Please check out the updated explainer here. Proposed spec changes: https://github.com/w3c/pointerevents/pull/495

[tomrittervg]

I reviewed the privacy concerns of this draft - it raises a valid point for fingerprinting purposes, but I can easily think of at least two more:

• a user's fingerprint is made more unique by the number of input devices a page can see. A user that presents with 4 pen devices is pretty unusual. I don't know enough about the hardware to know if this would occur only if a user literally picks up and uses four different styluses, or if a single stylus can present as four different ones based on e.g. holding a button down. If it's the latter, this risk is more pronounced than the former.
• a user's fingerprint is made more unique by the properties of the input device. This API immediately separates users into two buckets: those with a device that supports getting a unique hardware id, and those that don't.

[sahirv]

• If it's the latter, this risk is more pronounced than the former.

It's the former.

I think you raise great points on fingerprinting. The risks you mentioned seem to be inherent to the API that is proposed here. I would like to try to allay some of your concerns.

We are only going to be introducing the ability to count how many unique pen pointing devices are being used in a session. I would classify this as having low entropy. Furthermore, it is also not passive fingerprinting; the site only gets this information if the user actually uses the device(s) within a given session. There's no guarantee that a user that uses all 4 pens in one session will still use all 4 in the next. That lack of guarantee that the same user will always have the same number of devices should also help.

Ultimately, I'm hoping that the value provided from this API will outweigh the little bit of entropy being introduced. Would love your thoughts/position; I'd be happy to add these points to the explainer as well.

[sahirv]

Update: The proposed design has been reverted to the initial concept of having an id on the PointerEvent. Context: https://github.com/w3c/pointerevents/pull/495