I'm not sure if checking that in the browser would make sense here because the allow attribute restriction is specified in the DOM and the browser process isn't involved. I did ask this in the slack channel and pretty much got the same response that the renderer should be enforcing this check. If you have any other ideas though, then please let me know!
From: Dave Tapuska <[email protected]> Sent: Wednesday, October 27, 2021 2:27 PM To: Anupam Snigdha <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Bo Cupp <[email protected]>; Scott Low <[email protected]>; [email protected]; [email protected] Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API I was looking at the implementation of this. Is it possible to move the check of the policy to be based in the browser when the map is fetched? As of right now the policy enforcement is on the renderer side, so a compromised renderer can request the keyboard map. dave. On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <[email protected]<mailto:[email protected]>> wrote: Created an issue to get feedback from TAG: https://github.com/w3ctag/design-reviews/issues/685<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F685&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268251129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FQQPxFtkWm7mlvljFCgRJqjQYTK7vA6SOUa%2FTKoxDcw%3D&reserved=0> I added this to the webappsec-permission policy: https://github.com/w3c/webappsec-permissions-policy/pull/428<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebappsec-permissions-policy%2Fpull%2F428&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268261122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3huSRtIRvPEdaKXk0FRkPNSHWNgxUEtAAqt%2BP3BgWpo%3D&reserved=0>, but will also create an issue to investigate Permissions API integration. Thanks! From: Alex Russell <[email protected]<mailto:[email protected]>> Sent: Thursday, October 21, 2021 12:21 PM To: blink-dev <[email protected]<mailto:[email protected]>> Cc: Yoav Weiss <[email protected]<mailto:[email protected]>>; Anupam Snigdha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Bo Cupp <[email protected]<mailto:[email protected]>>; Scott Low <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Domenic Denicola <[email protected]<mailto:[email protected]>> Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API Not consulting the TAG in this instance may have been an error. In general, we should be putting things into consistent surfaces that they affect. In this case, it seems like we're missing integrations w/ the Permissions API. I'm LGTM2 on this intent contingent on a commitment to follow up w/ the TAG as an FYI and a commitment to investigate Permissions API integration. Best Regards, Alex On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote: LGTM1 On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola <[email protected]<mailto:[email protected]>> wrote: Just chiming in from the sidelines: in general I think this sort of exposure via permissions policies is a good thing, and should be encouraged. It shouldn't have any additional concerns for an API like this which is about exposing information: * Same-origin iframes can already call top.navigator.keyboard.getLayoutMap() * The parent can call navigator.keyboard.getLayoutMap(), serialize the information, and send it to any cross-origin descendants that it wants to receive that information via postMessage(). Permissions policy just streamlines this: same-origin iframes now don't need to go via top, and the parent can avoid writing custom code to communicate the information to cross-origin descendants, instead replacing it with a simple allow="keyboard-map" or allow="keyboard-map https://specific-origin";. I hope the API owners can support this kind of improvement to the platform, not only for this case but in general whenever we introduce ergonomic permissions policy-based delegation for any feature. On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev <[email protected]<mailto:[email protected]>> wrote: getLayoutMap() can already be accessed by the top level browsing context and I believe it does have fingerprinting concerns: a site can gain knowledge of the keyboard layout of the user even before the user has typed anything. Try this site switching between French and English keyboard layouts: https://fortunate-onyx-wren.glitch.me/french-or-english.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffortunate-onyx-wren.glitch.me%2Ffrench-or-english.html&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268271118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Un16Kmy1207Jykvs72lWQhwtpDB367iBUS1Cc3bmNxI%3D&reserved=0>. The privacy mitigation section<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwicg.github.io%2Fkeyboard-map%2F%23privacy-mitigations&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268271118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2BtK2a27cpzCEtih%2F4biHKAp76xMkJUoyZC%2FFISamCA%3D&reserved=0> describes some mitigations we could add for fingerprinting related concerns. I don't think exposing this by default to same origin iframes and allowing the top-level browsing context to delegate its authority to use getLayoutMap() to other iframes increases the concern any. If I'm thinking about that wrong please let me know. For the privacy section: I'll make a change to add permission policy along with the top level browsing context restriction to the spec. From: Yoav Weiss <[email protected]<mailto:[email protected]>> Sent: Friday, October 15, 2021 5:46 AM To: blink-dev <[email protected]<mailto:[email protected]>> Cc: Anupam Snigdha <[email protected]<mailto:[email protected]>>; Bo Cupp <[email protected]<mailto:[email protected]>>; Scott Low <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Yoav Weiss <[email protected]<mailto:[email protected]>> Subject: Re: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API Reading through https://wicg.github.io/keyboard-map/#privacy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwicg.github.io%2Fkeyboard-map%2F%23privacy&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268281114%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BxpMmo1sqMLm185lgCq8OuyIgZKllHIiEBuz%2B2CAZc8%3D&reserved=0> the only risk here is increased fingerprinting surface. Is that correct? (aside - the privacy section states that the API is only available in top-level contexts. You probably want to change that) On Thursday, October 14, 2021 at 10:09:04 PM UTC+2 snianu wrote: Can you clarify what the current situation is? getLayoutMap() which is part of the Keyboard API can only be accessed in the top browsing context which cuts off access from same and cross origin iframes. With this permission policy based solution, the default value would be "Self" that grants access to same origin iframe by-default, but requires web authors to add the "keyboard-map" value to allow attribute in order to grant access within cross-origin iframes. IIUC, currently layout maps are not available at all to iframes. Is that correct? Correct. Also, are you suggesting to add a permission policy that would enable it by default for same-origin iframes, and enable explicit delegation for cross-origin iframes? Yes. -Anupam From: Yoav Weiss <[email protected]<mailto:[email protected]>> Sent: Thursday, October 14, 2021 12:29 PM To: blink-dev <[email protected]<mailto:[email protected]>> Cc: Anupam Snigdha <[email protected]<mailto:[email protected]>>; Bo Cupp <[email protected]<mailto:[email protected]>>; Scott Low <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API On Tuesday, October 12, 2021 at 12:33:19 AM UTC+2 snianu wrote: Contact emails [email protected]<mailto:[email protected]> Explainer https://github.com/WICG/keyboard-map/issues/38<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fkeyboard-map%2Fissues%2F38&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268291103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4VDVM8kpDEixMO3xEnq%2FcqFLcz6euA5NqV%2BO9pidzas%3D&reserved=0> Specification https://wicg.github.io/keyboard-map/#permissions-policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwicg.github.io%2Fkeyboard-map%2F%23permissions-policy&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268301101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B9IR8y1iyYrKrhabUlNpNQQK%2FF4cq80k5Kbt74n1tC8%3D&reserved=0> Summary getLayoutMap() used in conjunction with code solves the problem of identifying the actual key pressed in keyboard with different layout maps such as English vs French keyboards, but since getLayoutMap() isn't available in all contexts (can't be used inside iframes), Office web apps like Excel, Word, PowerPoint, etc. that show up as embedded experiences in Outlook Web, Teams, etc. and are running in iframes, can't use this API. Adding keyboard-map to the allow attribute list solves this problem. Can you clarify what the current situation is? IIUC, currently layout maps are not available at all to iframes. Is that correct? Also, are you suggesting to add a permission policy that would enable it by default for same-origin iframes, and enable explicit delegation for cross-origin iframes? See this<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fkeyboard-map%2Fissues%2F38&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268311098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qqAd%2BfesRM%2FineyQxCPnQQUT8lKgUTmI5%2Fvtc5MZ3h0%3D&reserved=0> Github issue for more info. Blink component Blink<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268311098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RM9yTJSC70QE5EutPfEMuEthdBb7IsfJsGEZd0bqk8E%3D&reserved=0> Search tags keyboard-map<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeatures%23tags%3Akeyboard-map&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268321089%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZExc4SxFgMgDXqkkiE7cTVnXFoS%2BCM7H29Kr3SyQoeg%3D&reserved=0>, Keyboard<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeatures%23tags%3AKeyboard&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268331086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VKRcXfUzjP99oQsXd5m%2F9squq3fskqMDhi6C3ugwrcc%3D&reserved=0> TAG review Not applicable as this is API has been shipped. TAG review status Not applicable Risks Interoperability and Compatibility Currently Keyboard API is not supported on Safari and Firefox so interop risk is minimal. Moreover, this proposal only allows the usage of the Keyboard API inside an iframe if it's explicitly specified in the allow attribute list by the web author. The feature policy names are based on the permission names, which have been part of the permission policy spec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebappsec-permissions-policy%2F&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268341077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uyaicPuKSt26ZAqu9laR0f5JK9c7Ajngpz7wEZW8esA%3D&reserved=0>. Gecko: Negative (https://github.com/mozilla/standards-positions/pull/310<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fpull%2F310&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268341077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1sCHcSZjcHnvqv6wkXu660QJiNv2dGIntjvm8UBRCTs%3D&reserved=0>) WebKit: Negative (https://github.com/WICG/keyboard-map/issues/30#issue-487691188<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fkeyboard-map%2Fissues%2F30%23issue-487691188&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268351073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1tolxD4eajJtXm7vV5PI4bGa%2B7Rsjsje8fzQTpDKN7w%3D&reserved=0>) Web developers: Positive (https://github.com/WICG/keyboard-map/issues/38#issue-934823530<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fkeyboard-map%2Fissues%2F38%23issue-934823530&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268361067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WRwiva6ucZ0qH1tb5%2FIVwZJfm6cW2H73xnXnTiwYvbg%3D&reserved=0>) Ergonomics None. Activation None. Security While there are fingerprinting concerns, this API has been shipped in Chrome 69 and adding to the allow attribute list (like HID, clipboard-read/write etc) allows sites like Office web apps to use this API. The default value would be "self" (= top-level browsing context) but sites could add it to allow list to access within iframe context. Debuggability The allow attribute has basic tooling support as described in this<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eJn5QIX4JFGackDYmdLxWXEmTDkSGj_ZGz5XY4uCKbY%2Fedit&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268371063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wisKdWoOpViQF8OJxY7wFbdGrGBNynmflSneq3ymQX4%3D&reserved=0> doc. 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%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268381056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WqeL9zGZcL8x1GfcfUPROtab2Ya3bKgHdYmoL9HzQ%2FE%3D&reserved=0>? Yes Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1258242<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1258242&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268381056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2ZtqmY4DDHDP2QZ1e%2Fos7xToGrH77d0DklMXVW001Fk%3D&reserved=0> Estimated milestones 97 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5657965899022336<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5657965899022336&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268391052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vXocstrXTszKJsee2vjODM985oM8rrp4HbIaOwSYm8A%3D&reserved=0> This intent message was generated by Chrome Platform Status<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2F&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268401446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z0rsoQ5KtolpCGKAHXv1ORxCmjH3YkOx9cl6lk2AcIE%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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB038743E3690A397D6851C7F5CFB99%40BL0PR00MB0387.namprd00.prod.outlook.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FBL0PR00MB038743E3690A397D6851C7F5CFB99%2540BL0PR00MB0387.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268411040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tym1cG56v4dlJjomylzvKIyx3Sn1AD7v37kAb6VagmE%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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB039046006135653C635811A0CF859%40DM5PR00MB0390.namprd00.prod.outlook.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FDM5PR00MB039046006135653C635811A0CF859%2540DM5PR00MB0390.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C65051870c3d842ee922008d999908204%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637709668268421041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mQ0u%2BFU8xUIPBPtTkVGGnR8O65dsSJyrpUJRz7wyweM%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0390878B0E6D335456F31C27CF859%40DM5PR00MB0390.namprd00.prod.outlook.com.
