Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider extending uBlock Privacy with keyboard-map permission policy #20142

Closed
6 tasks done
bershanskiy opened this issue Oct 18, 2023 · 4 comments · May be fixed by #20143
Closed
6 tasks done

Consider extending uBlock Privacy with keyboard-map permission policy #20142

bershanskiy opened this issue Oct 18, 2023 · 4 comments · May be fixed by #20143

Comments

@bershanskiy
Copy link
Contributor

Prerequisites

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 added a commit to bershanskiy/uAssets that referenced this issue Oct 18, 2023
@MasterKia
Copy link
Member

MasterKia commented Oct 18, 2023

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
Copy link
Contributor Author

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)

@bershanskiy
Copy link
Contributor Author

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
Copy link
Member

cc @maymen1

@uBlockOrigin uBlockOrigin locked and limited conversation to collaborators Oct 19, 2023
@mapx- mapx- converted this issue into discussion #20159 Oct 19, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants