Extending the PointerEvent with Unique DeviceId Attribute

[bmathwig]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Extending the PointerEvent with Unique DeviceId Attribute
• Explainer (if not README.md in the repository): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

Design reviews and vendor positions

• Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/715

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;
}

[johnwilander]

Hi! Thanks for filling. Sorry if what I'm asking about below is in the spec. I'm just going off what you write here to get the conversations started.

provide developers with persistent unique identifiers

Persistent implies stored to disk and persisted between browsing sessions. But the rest of your text implies ephemeral, i.e. in-memory and tied to the browsing session (or the document). Which is it?

persistent for the life of the document

I already asked about "persistent" above. But does this mean that a navigation, a close of the document, or a reload of a document would discard the ID?

regenerated during a new browsing session

A browsing session in the terminology I use means the time the browser is running. That is very different from the lifetime of a document. Sure there can be a document that lives the whole browser session but most documents don't and some are super short-lived.

I think the ID needs to be regenerated when the user deletes website data for the origin (if we're talking really unique IDs – see next paragraph).

In what way does this ID need to be unique? Unique per document, unique to the browsing session, or globally unique like a UUID? It seems your use case only needs to tell devices apart per document, in which case we could just start with device 1 and increment from there, right?

[bmathwig]

It seems your use case only needs to tell devices apart per document, in which case we could just start with device 1 and increment from there, right?

Yes, this is correct. The implementation would start with ID 1 or 0 and increment as new devices are introduced to the document. There is an open question whether the ID should reset on document refresh or if it should stay the same between refresh, but be unique per-origin to avoid information leak between origins.

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

[annevk]

@sahirv I don't think an attribute can return a dictionary. We also usually don't add tear-off objects. Especially for events with event constructors it's not clear that will work well.

[sahirv]

My apologies, I had pasted a stale version of the changes made. I have since made an edit to the comment. Could you elaborate on what you mean by tear-off object? Here is the PR against the pointer event spec for further implementation details: https://github.com/w3c/pointerevents/pull/495

[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