Consider extending uBlock Privacy with keyboard-map permission policy

[bershanskiy]

Prerequisites

• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• I am running the latest version of uBlock Origin (uBO).

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

ublock-privacy list already has directives for a few privacy-hostile permissions. I propose adding keyboard-map directive.

This directive controls Keyboard Map API (specification) which specifies navigator.keyboard.getLayoutMap() method (MDN docs). This API exposes a significant amount of fingerprintable data for users of non-standard keyboard layouts or users with unusual keyboards, while not informing the user about its usage. This API has very little practical utility, it can be mostly used just for shortcut management in web productivity programs (think user who uses Dvorak layout pressing Ctrl+Z shortcut but program actually receiving something like Ctrl+Q) and browser video games (like user trying to use AWSD keys for walking but program receiving A,OE keys). These use cases are rater rear/weak and are solved much better via website-specific custom settings UI which offers user to select an action and then press the desired key combination to assign it). Both Mozilla and Apple opposed this feature on these grounds and declined implementing it.

Mozilla position:

We're concerned that this exposes keyboard layouts, which seem likely to be a significant source of fingerprinting data, in a way that does not require any user interaction.

Apple position:

[T]he WebKit team at Apple is not interested in implementing this feature as currently proposed / spec'ed.

Brave disables Keyboard Map API (sets navigator.keyboard to null) when their "Brave Shields" are enabled since 2021 (source).

Example reproduction:

1. Open https://example.com
2. Enable a few different keyboards in your OS, e.g. English and Dvorak (DV).
3. Run this in the console and observe the output with different keyboard layouts:

   var keyboard = {};
   navigator.keyboard.getLayoutMap()
   .then(keyboardLayoutMap => {
     keyboardLayoutMap.forEach((value,key,map) => {keyboard[key] = value})
     console.log(keyboard)
   });

4. Observe the following layouts
   For standard English keyboard:

   {KeyE: "e", KeyD: "d", Minus: "-", KeyH: "h", KeyZ: "z", ...}

   For Dvorak keyboard:

   {KeyE: ".", KeyD: "e", Minus: "[", KeyH: "d", KeyZ: ";", ...}
   

URL(s) where the issue occurs.

https://example.com

Screenshot(s)

No response

uBO version

1.52.2

Browser name and version

Chromium 118.0.5993.70

Settings

• None

Notes

No response

[MasterKia]

See: WICG/keyboard-map#38

I'm a developer in the Excel Online application, working specifically on keyboard shortcuts.

Our application is hosted as a sub-context inside of an iframe element in the dome, where the top-level context can be many different endpoints - SharePoint, OneDrive, Teams, etc. That means the API is not available for us to use from inside the app code.

In addition to that, keyCode is deprecated, and there doesn't seem to be any alternative API to handle keyboard shortcuts for different layouts, other than getLayoutMap().

Should the keyCode property actually be removed one day - we believe all Office Online applications (PowerPoint, Word, OneNote, etc.) will require this or similar API to handle their keyboard shortcuts for different layouts.

[bershanskiy]

I was playing with this PR and I believe Chromium currently has a bug which prevents Permissions Policy from working. In particular, I see that

1. before this PR, document.featurePolicy.allowsFeature('keyboard-map') returns true and keyboard map is available, as expected
2. after this PR, document.featurePolicy.allowsFeature('keyboard-map') returns false but keyboard map is still available, even though the promise should be rejected (source)

[krystian3w]

How possible check this in Firefox if one day they implement it?

[gorhill]

So until they fix this bug, there is not much point to add the filter?

[bershanskiy]

Should the keyCode property actually be removed one day - we believe all Office Online applications (PowerPoint, Word, OneNote, etc.) will require this or similar API to handle their keyboard shortcuts for different layouts.

Yes, keyboard shortcuts for different layouts is the primary use case for this API. All modern browsers support KeyboardEvent/code which is an explicit successor to KeyboardEvent.keyCode. Both KeyboardEvent.code and KeyboardEvent.keyCode expose this information, for better or worse (they can facilitate fingerprinting, but do require user interaction for each key). This is explicitly mentioned in the spec.

[MasterKia]

cc @maymen1

[mapx-]

@gorhill