1. What information does this feature expose, and for what purposes? It exposes a mapped device id of pen devices in a pointer event, for the purpose of identifying that hardware for the document session. A use case is multi-pen input on one device at the same time, and assigning a different color to each pen.
2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality? Yes
3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either? No personal information or PII is exposed, only the fact that a user is using a pen device and how many pens they use.
4. How do the features in your specification deal with sensitive information? Sensitive information like the hardware id are not exposed.
5. Do the features in your specification introduce state that persists across browsing sessions? No.
6. Do the features in your specification expose information about the underlying platform to origins? No.
7. Does this specification allow an origin to send data to the underlying platform? No.
8. Do features in this specification enable access to device sensors? No.
9. Do features in this specification enable new script execution/loading mechanisms? No.
10. Do features in this specification allow an origin to access other devices? No.
11. Do features in this specification allow an origin some measure of control over a user agent's native UI? No.
12. What temporary identifiers do the features in this specification create or expose to the web? A device id.
13. How does this specification distinguish between behavior in first-party and third-party contexts? Same as pointer events.
14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? No change.
15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections? Yes.
16. Do features in your specification enable origins to downgrade default security protections? No.
17. What happens when a document that uses your feature is kept alive in BFCache instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document? The device Id's would not be reset; in chromium they are assigned a value from 2 onwards, with the first device to interact getting 2.
18. What happens when a document that uses your feature gets disconnected? No change.
19. What should this questionnaire have asked?

Hi @sahirv - thanks for sending this our way. We discussed in our call today

The motivation (user need) seems to make sense.

We wanted to clarify - it seems there is no way to persist device IDs across sessions with the current design. In your example, if your session is interrupted your color assigned to each device might swap. Is that the intention?

We're also concerned about the usefulness of this for devices that don't have a hardware ID - since it seems they wouldn't be able to be differentiated within a session?

For devices with a hardware ID, would the deviceId be the same as the pointerId? If so, maybe this could just be a flag indicating that the pointerId is stable? If not, why not?

Also can you clarify where this work will end up for standardization. It seems that this belongs in the Pointer Events Working Group - but that group is due to close off in a month. Is the intention to open up this group again for further updates, or do you envision bringing this to WebApps or some other working group?

Thanks for your response!

We wanted to clarify - it seems there is no way to persist device IDs across sessions with the current design. In your example, if your session is interrupted your color assigned to each device might swap. Is that the intention? Yes in the current design, the device id does not persist across sessions, only through the session. Persisting the device id across sessions would introduce some further questions - such as how long to keep the device id, preventing fingerprinting (if for example multiple people use one browser with their own pens).

We're also concerned about the usefulness of this for devices that don't have a hardware ID - since it seems they wouldn't be able to be differentiated within a session? Devices with no hardware ID will not have a device id in the current design. Perhaps in lieu of the hardware ID itself, we can use other features that the device has implemented to differentiate itself from other devices. If there is no such feature in the device, then the device ID can't work by nature.

For devices with a hardware ID, would the deviceId be the same as the pointerId? If so, maybe this could just be a flag indicating that the pointerId is stable? If not, why not? We considered repurposing pointer id as the device id. However, the main issue we ran into was that in some instances, the physical device does not provide a hardware id. An example is the surface pen on the pointer down. When creating the PointerDown event, the browser needs to have a pointerId. For the subsequent PointerMove, a device Id is present, but the pointerId can't change for the stroke. Therefore, it makes sense to have the two separate values to indicate the state.

Also can you clarify where this work will end up for standardization. It seems that this belongs in the Pointer Events Working Group - but that group is due to close off in a month. Is the intention to open up this group again for further updates, or do you envision bringing this to WebApps or some other working group? We're currently going through the WICG and will work on an extension spec. I'm not quite sure which WG will end up owning the Pointer Events/Events space, but we are happy to work with anyone willing to take this on.

Hi there, quick question: Does the device id of the same device persist within the same session if the device disconnects and reconnects? We were just discussing that the user expectation is likely that it would.

Yes if the device re-connects to the same session, it will and should have the same deviceId.

Sounds good. That was our only concern, so we're happy to see this moving forwards. Thanks for flying TAG!