-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending the PointerEvent with Unique DeviceId Attribute #102
Comments
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.
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?
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?
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? |
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. |
The shape of this API has changed. It now takes the following form:
Please check out the updated explainer here. |
@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. |
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? |
Update: The proposed design has been reverted to the initial concept of having an id on the |
Request for position on an emerging web specification
Information about the spec
Design reviews and vendor positions
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 toPointerEvent
in order to safely provide developers with persistent unique identifiers for their inking applications.Problems with Current Solutions
Currently, the
pointerId
attribute onPointerEvent
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 usepointerId
as a fixed value for pen devices that do support fetching a unique hardware ID, how would we handle devices that do not? ThepointerId
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:
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
The text was updated successfully, but these errors were encountered: