New keyboard API will let online Office apps handle shortcut keys better
Google Chrome 97 arrived on Tuesday, bringing with it a Microsoft-backed keyboard API rejected by Apple and Mozilla on privacy grounds. Microsoft developers proposed the change – called Feature policy for Keyboard API – because web applications such as Excel Online run within an iframe that cannot access a browser API for determining how the physical keys on a keyboard have been mapped to specific keyboard layouts. The update to Chrome (Version 97.0.4692.71) adds support for the Keyboard Map specification, which provides a way to convert a code representing the pressed key on a keyboard to the value generated by pressing the key. The value returned varies, depending on locale (e.g., «en-US»), layout (e.g., «dvorak») and modifier state (e.g., «Shift + Control»); the code is tied to the platform-neutral scancode associated with each physical key. The Keyboard.getLayoutMap() API provides a way to get specific information about how keyboards are mapped. But it’s not available in an iframe or sub-context due to the way browser security has been designed. So there’s potential ambiguity where, for example, a user has both French and Japanese keyboard layouts installed and the current active layout and locale are Japanese – Excel Online in this instance would need to guess which Latin-character-based keyboard shortcut in the app corresponds with the non-Latin character sent by the user. The addition of Keyboard Map to Chrome 97 means the Keyboard Map can be used in conjunction with the getLayoutMap() method, which Microsoft intends to use to make keyboard shortcuts work better in its online Office apps. Apple and Mozilla, however, are not fans because the change represents a privacy rollback. As Apple software engineer Ryosuke Niwa wrote in a GitHub Issues post in 2019, «the Keyboard Map API as proposed exposes a high entropy fingerprinting surface. This is not acceptable from [a] privacy perspective.
