________________________________ From: Rick Byers <rby...@chromium.org> Sent: Wednesday, December 14, 2022 1:05 PM To: Ben Mathwig <benjamin.math...@microsoft.com> Cc: blink-dev <blink-dev@chromium.org>; Mustaq Ahmed <mus...@google.com>; fla...@chromium.org <fla...@chromium.org>; Sahir Vellani <sahir.vell...@microsoft.com>; Ben Mathwig <benjamin.math...@microsoft.com> Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: PointerEvent.deviceId for Mult-Pen Inking
You don't often get email from rby...@chromium.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Mon, Dec 12, 2022 at 1:07 PM 'Ben Mathwig' via blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>> wrote: --- Sahir & Ben: wondering why a new deviceId field seems more logical now against the original proposal of repurposing the pointerId field? Is it because of the compat concern you raised in w3c/pointerevents/issues/353<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353%23issuecomment-1346776842&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01VF%2FXH9E%2FAUhsZXbQhd4irjmMNlWxyIj9rYZcKDTwQ%3D&reserved=0>? --- The primary reason is the deterministic nature of deviceId compared to pointerId. The scenario would be: (a) If the device supports getting a unique hardware identifier, we randomly generate an integer and persist that integer for the document lifespan. (b) If the device does not support getting a unique hardware identifier, does pointerId fall back to its original behavior? In the spec, we decided between null, undefined, and integer as the deterministic values of deviceId. We could use pointerId instead, but we'd have to align on the solution for (b) I guess we should take this to a GitHub repo somewhere, but I can't help but interject: sounds like a pretty good use case for InputDeviceCapabilities<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FInputDeviceCapabilities&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HCNZsP13%2B%2FAfS3SWOWd9fbw79yXa3kFnWElJzq8VulU%3D&reserved=0> to me (i.e. 'hasDeterministicPointerId') ☺. Perhaps along with a boolean on the event for the limitation case discussed in the explainer. TIL! Just so I understand this correctly, we would have something like: event.sourceCapabilities.hasDeterministicPointerId as a check to let the web developer know that the event.pointerId is a valid device ID? Jeffrey had made a similar suggestion about mitigating the potential confusion of null/undefined by adding a separate boolean. Open to moving this discussion to the appropriate forum. On Monday, December 12, 2022 at 8:08:11 AM UTC-8 Mustaq Ahmed wrote: Supporting consistent IDs for supported pens sounds great. Sahir & Ben: wondering why a new deviceId field seems more logical now against the original proposal of repurposing the pointerId field? Is it because of the compat concern you raised in w3c/pointerevents/issues/353<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353%23issuecomment-1346776842&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01VF%2FXH9E%2FAUhsZXbQhd4irjmMNlWxyIj9rYZcKDTwQ%3D&reserved=0>? On Thu, Dec 8, 2022 at 5:16 PM Rick Byers <rby...@chromium.org> wrote: On Thu, Dec 8, 2022 at 1:17 PM Sahir Vellani <sahir....@microsoft.com> wrote: Thank you for all the feedback! Rick, yes that’s correct. The ID will be refreshed on reload and iframes will have a different ID to their parent/each other. Also, we can definitely explore integration with web driver and adding a WPT test. Perfect. I'm not a privacy reviewer, but that makes a lot of sense to me. Ben, any thoughts on the PEWG path Rick mentions below? Sounds<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vh5oZuMKrcIaF5LaqSFGmQNFkhNrIxLE4c8O17TD%2B8s%3D&reserved=0> like the current editor / WG chair prefers a WICG spec until L3 gets finalized anyway. But knowing it's just a process thing and can trivially be moved into the PE spec once L3 reaches REC seems good enough to me. Sahir From: Rick Byers <rby...@chromium.org> Sent: Tuesday, December 6, 2022 12:34 PM To: Sahir Vellani <sahir....@microsoft.com>; Mustaq Ahmed <mus...@chromium.org>; Robert Flack <fla...@chromium.org> Cc: blin...@chromium.org; Ben Mathwig <benjamin...@microsoft.com> Subject: [EXTERNAL] Re: [blink-dev] Intent to Prototype: PointerEvent.deviceId for Mult-Pen Inking You don't often get email from rby...@chromium.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Cool, looks like a nice little addition to me. +Mustaq Ahmed and +Robert Flack from the Chrome interactions team who are likely code reviewers. The only real potential debate I see is around the details of the privacy protections. If I understand correctly "per document instance" means that the IDs will even be different across iframes in the same tab, and also when a page is reloaded. Is that right? If so, I can't see how it would be an issue. On Mon, Dec 5, 2022 at 12:49 PM 'Sahir Vellani' via blink-dev <blin...@chromium.org> wrote: Contact emails bema...@microsoft.com, sahir....@microsoft.com Explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EsOgFOzsHPc%2Fj%2F%2BTJ9hflwtRxorbyd7hF41%2BLjI0ZBU%3D&reserved=0> Specification https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EsOgFOzsHPc%2Fj%2F%2BTJ9hflwtRxorbyd7hF41%2BLjI0ZBU%3D&reserved=0> FWIW with my former PointerEvents spec editor hat on, I pinged this issue<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=osa71PvGzL%2BDGjx39Axkb1caplRW7jqxnGzlzRNz57U%3D&reserved=0> on the PointerEvents spec. We've had 'extensions' to the PointerEvents spec in the past, so the PEWG may be amenable to something simple and pragmatic that'll naturally make it into the next official PE spec rather than starting with WICG. But with my Blink API owner hat on, either path is fine. Summary As devices with advanced pen input capabilities are becoming increasingly prevalent, it is important that the web platform continues to evolve to fully support these advanced features in order to unlock rich experiences for both end users and developers. One such advancement is the ability for a device's digitizer to recognize more than one pen device interacting with it simultaneously. This feature is an extension to the PointerEvent interface to include a new attribute, deviceId, that represents a session-persistent, document isolated, unique identifier that a developer can reliably use to identify individual pens interacting with the page. Blink component Blink>Input<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EInput&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EFrGRopXCM0LJfTkMGXloPUsfPM6kTU%2BXNGfDqTMiGw%3D&reserved=0> Motivation Currently, developers have no way to distinguish between two individual pens on an ink-enabled digitizer. The existing PointerEvent.id attribute is implemented in different ways and does not always persist for each ink stroke or interaction with the screen. Developers can use this change to have a secure and reliable way to identify individual pen (pointers) interacting with the screen in order to set specific colors or pen shapes for each device interacting with the digitizer. Initial public proposal https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ICpPXSjDr6YIR8kUwmRvDc5PvqGmMBJ9WxGi64ZagHU%3D&reserved=0> TAG review TAG review status Pending Risks Fingerprinting risks, which will be mitigated by randomizing the ID each renderer session. Interoperability and Compatibility Gecko: Request for Position: Extending the PointerEvent with Unique DeviceId Attribute · Issue #715 · mozilla/standards-positions · GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F715&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q5R7V4mQDV01AEkBJiY%2BG2OKdAgomwlJy4thA%2FagGMI%3D&reserved=0> WebKit: Request for Position: Extending the PointerEvent with Unique DeviceId Attribute · Issue #102 · WebKit/standards-positions · GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWebKit%2Fstandards-positions%2Fissues%2F102&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=50aSzcEF%2FTZiR2ai679NTDXYbD749Ranuj4mtXZqEBw%3D&reserved=0> Web developers: No signals Other signals: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability deviceId will be available via DevTools for front-end debugging. Is this feature fully tested by web-platform-tests<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmain%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WU1d6ffoGTwByu5JTQRHftrquyyf78MKEOF3TrEpfcc%3D&reserved=0>? No We've got automation plumbing for the rest of PointerEvents I believe. Any reason not to add plumbing through WebDriver for this too and an automated WPT test? I suppose the value is pretty low, but IMHO would be nice if it's not too much more expensive than the alternative chromium-only tests. Flag name PointerEventDeviceId Requires code in //chrome? False Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5114132234240000<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F5114132234240000&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LPPFhNDrpyutVflW4%2FZ6SAYCTi4pBbaCSpJY4RzaoCQ%3D&reserved=0> This intent message was generated by Chrome Platform Status<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2F&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SGZ6z4qV1VTSTgPJrwJf86sEkxaJe329cJgqVwSNJWA%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA0PR00MB1033E5DE0BDE42239E647E9AFB189%40SA0PR00MB1033.namprd00.prod.outlook.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FSA0PR00MB1033E5DE0BDE42239E647E9AFB189%2540SA0PR00MB1033.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y4lyVXVYRJyoigfHIJXAjWYcXPEk1IT50O3inXUyBTw%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/870380fe-ab9a-4925-8db1-261efa233295n%40chromium.org<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2F870380fe-ab9a-4925-8db1-261efa233295n%2540chromium.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QmNuOrk%2BuTR5eryN3Wfpb6zkLQD4f2iTXsW%2FEIrzxJ8%3D&reserved=0>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB1031EE3832A90B169D50FCC1FBE09%40PH0PR00MB1031.namprd00.prod.outlook.com.
