#685: Feature policy for Keyboard API
Discussions
2021-12-Madripoor
Dan: fingerprinting issue
Yves: yes but less intrusive than the font list
Lea: I think this feature adds a lot of value
Sangwhan: this increases risk for outliers - people who use minority keyboards.
Yves: accessibility devices as well?
Sangwhan: A small subset of users who rely on AT can be fingerprinted... So if your IP is french, your language is french, and keyboard is us-english then that fingerprints you... However the gains outweigh the risks. So many other ways to detect these kinds of outliers.
Yves: I agree.
Dan: Someone want to leave a closing comment?
Sangwhan: good idea.
OpenedOct 27, 2021
Braw mornin' TAG!
I'm requesting a TAG review of adding a feature policy for Keyboard API.
The Keyboard API has been shipped, and this change just adds a new feature policy so web authors can access it from same/cross origin iframes. We wanted to get TAG's opinion on this change. Here is a brief 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.
Further details:
You should also know that... Here is an existing issue describing the problem: https://github.com/WICG/keyboard-map/issues/38
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify [snianu]