Intent to Implement and Ship: Feature policy for Keyboard API

[Anupam Snigdha]

Contact emails

sni...@microsoft.com

Explainer

https://github.com/WICG/keyboard-map/issues/38

Specification

https://wicg.github.io/keyboard-map/#permissions-policy

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.

See this Github issue for more info.

Blink component

Blink

Search tags

keyboard-map, Keyboard

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.

Gecko: Negative (https://github.com/mozilla/standards-positions/pull/310)

WebKit: Negative (https://github.com/WICG/keyboard-map/issues/30#issue-487691188)

Web developers: Positive (https://github.com/WICG/keyboard-map/issues/38#issue-934823530)

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

Is this feature fully tested by web-platform-tests?

Yes

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1258242

Estimated milestones

97

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5657965899022336

This intent message was generated by Chrome Platform Status.

 

[Yoav Weiss]

On Tuesday, October 12, 2021 at 12:33:19 AM UTC+2 snianu wrote:

Contact emails

sni...@microsoft.com

Explainer

https://github.com/WICG/keyboard-map/issues/38

Specification

https://wicg.github.io/keyboard-map/#permissions-policy

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?

[Anupam Snigdha]

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

[Yoav Weiss]

Reading through https://wicg.github.io/keyboard-map/#privacy 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)

[Anupam Snigdha]

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. The privacy mitigation section 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.

[Gary Kacmarcik (Кошмарчик)]

On Fri, Oct 15, 2021 at 5:45 AM Yoav Weiss <yoav...@chromium.org> wrote:

Reading through https://wicg.github.io/keyboard-map/#privacy the only risk here is increased fingerprinting surface. Is that correct?

 

I don't believe this change (adding a permission policy) increases the fingerprinting surface in a practical way over the API that is already shipping. But my assumption here is that this permission will only be granted in rare cases.

And the fingerprinting mitigations for the base API still apply when accessed from an iframe.

[Domenic Denicola]

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.

--
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/BL0PR00MB038743E3690A397D6851C7F5CFB99%40BL0PR00MB0387.namprd00.prod.outlook.com.

[Yoav Weiss]

LGTM1

[Alex Russell]

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

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anupam Snigdha]

Created an issue to get feedback from TAG: https://github.com/w3ctag/design-reviews/issues/685

I added this to the webappsec-permission policy: https://github.com/w3c/webappsec-permissions-policy/pull/428, but will also create an issue to investigate Permissions API integration. Thanks!

LGTM1

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dave Tapuska]

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.

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.

[Anupam Snigdha]

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!

[Dave Tapuska]

For a cross origin renderer the browser process would be involved because the allow attribute restriction is in one renderer, and the enforcement of the permission is in the renderer that wants to use it. I do not think it is difficult to check the policy on the mojo request of the keyboard map in the browser process. Although you'll likely want some additional response enums.

I ask because we would need to adjust this model for fenced frames implementation and the enforcement on the browser side better aligns with our security design.

dave.

[Alex Russell]

Thanks for filing a TAG issue and an issue in permission policy. Would also like to make sure that there is integration with the Permissions API:

https://w3c.github.io/permissions/

On the question of browser signals, it's fine to note that Apple wasn't interested, but that probably isn't a reasonably strong signal.

LGTM1

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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.

--
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+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM3, (but follow up with Dave about the implementation details, and make sure to listen to any late comments from other reviews)

[Anupam Snigdha]

Thanks Daniel! I have opened a bug to investigate this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1264662

---

From: Daniel Bratell <brat...@gmail.com>
Sent: Thursday, October 28, 2021 12:22 PM
To: blink-dev <blin...@chromium.org>
Cc: Dave Tapuska <dtap...@chromium.org>; sligh...@chromium.org <sligh...@chromium.org>; blin...@chromium.org <blin...@chromium.org>; yoav...@chromium.org <yoav...@chromium.org>; Bo Cupp <pc...@microsoft.com>; Scott Low <sc...@microsoft.com>; gar...@chromium.org <gar...@chromium.org>; dom...@chromium.org <dom...@chromium.org>; Anupam Snigdha <sni...@microsoft.com>