Open Bug 1598862 Opened 5 years ago Updated 2 years ago

When resistFingerprinting is enabled, alt+letter JS keyboard hotkey bindings don't work

Categories

(Core :: Privacy: Anti-Tracking, defect, P5)

70 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: metastork, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fingerprinting][tor])

+++ This bug was initially created as a clone of Bug #1594532 +++

Resubmitting this, since I had closed the initial bug report before diagnosing the cause of the problem.

Summary:
If privacy.resistFingerprinting flag is enabled in Firefox 70 on Linux (possibly other platforms too), alt+letter hotkeys don't get recognised by JS in pages.

Steps to reproduce:
Set the privacy.resistFingerprinting flag to true in about:config.
Then try alt+letter combos at https://rawgit.com/jeresig/jquery.hotkeys/master/test-static-01.html (for JQuery hotkeys plugin) or https://wangchujiang.com/hotkeys/ (for a standalone JS hotkeys demo).

Actual results:
alt+[letter] hotkeys just register as plain [letter] presses (or not at all in some cases) and don't get captured by the JS as intended by the keyboard bindings.

Expected results:
Even when resistFingerprinting is enabled, alt+[letter] hotkeys should be captured by JS as alt+[letter] rather than plain [letter] (or not at all, in some cases).

Summary: alt+letter JS keyboard hotkey bindings don't work anymore → When resistFingerprinting is enabled, alt+letter JS keyboard hotkey bindings don't work

Definitely an Arthur/Tim question...

Whiteboard: [fingerprinting][tor]
Component: Protections UI → Privacy: Anti-Tracking
Product: Firefox → Core

(In reply to metastork from comment #0)

in Firefox 70 on Linux (possibly other platforms too) ...

same result in Firefox 70 on windows 7

Unfortunately, we spoof the modifier state of ALT keys when RFP is on. See here. So this is expected behavior. That's because some keyboard layouts rely on the ALT key to type certain letters, so it could reveal your real keyboard layout.

But the real question is that should we reveal the real state of ALT, as we did for Control key? I think it depends on how widely the ALT key be used as a combination key. But I don't have data to answer this question and don't see any related telemetry at first glance.

Thanks Tim, that's interesting. I wasn't aware keyboard layout could be used in fingerprinting - is it possible to find out via JS what a keyboard's Alt and/or AltGr do without the user explicitly pressing these keys?

You're right, Alt hotkeys definitely aren't as common as Ctrl, though they do seem to be in fair use in some popular webapps. I Just had a quick look at Office 365 Word, for instance, which uses Alt+Shift+A to launch accessibility help, Alt+Q for the command launcher, and Alt+F12 to navigate through comments (plus a few others). And Google Drive Sheets also uses Alt+Shift+A to launch the accessibility menu; Ctrl+Alt+V for paste format; Alt+Shift+letter to open the various menus; and quite a few other Ctrl+Alt and Shift+Alt combinations (though no plain Alt+Letter presses, it seems).

Priority: -- → P5

Regarding categorising this as a P5 (which I assume means that it likely won't get fixed?), I feel it should be slightly higher and would be grateful if it could be re-considered. As is, it causes FF's resistFingerprinting to break expected functionality and accessibility in quite a few widely-used apps and websites, which makes FF unsuitable for users relying heavily on hotkeys and could be a red flag if resistFingerprinting is to be enabled by default in future. Besides the above, I have noticed another few web-apps that heavily use Alt+key combinations, such as:

  • Jupyter Notebooks (the popular iPython environment), where lots of commands that are run repeatedly are bound to alt+keys,
  • MS Outlook email web version (alt+. and alt+s),
  • many Zoho apps use a lot of common Alt+ keys.

With the proviso that I don't know much about the topic so I may be completely wrong, it seems while the Alt keys do present a fingerprinting risk it would require significant intentional interaction between a user and a website beyond just browsing. It seems as though the user would have to specifically press the Alt key, which a user probably wouldn't do unless they're trying to access an alt+hotkey (which wouldn't work) or type a non A-Z character into an input field, at which point a script could theoretically guess anyway that the user had a non-standard keyboard layout that can easily output non-A-Z characters and try to do more nefarious things like try to fingerprint users' typing speed, patterns, etc.

In light of the above I would kindly request you to re-consider the disabling of Alt+ hotkeys, for the time being, by making this feature opt-in or at least opt-out via an about:config flag.

(In reply to metastork from comment #5)

Regarding categorising this as a P5 (which I assume means that it likely won't get fixed?)

P5 typically means we don't expect to write a patch for but would accept contributions that aligned with our goals.

I feel it should be slightly higher and would be grateful if it could be re-considered. As is, it causes FF's resistFingerprinting to break expected functionality and accessibility in quite a few widely-used apps and websites, which makes FF unsuitable for users relying heavily on hotkeys

Unfortunately, yes. RFP does cause breakage in certain situations. We try to ensure they affect a relatively small number of users but even still...

resistFingerprinting is to be enabled by default in future.

There are no plans for this. The level of breakage would be unacceptably high for a default feature.

Besides the above, I have noticed another few web-apps that heavily use Alt+key combinations, such as:

  • Jupyter Notebooks (the popular iPython environment), where lots of commands that are run repeatedly are bound to alt+keys,
  • MS Outlook email web version (alt+. and alt+s),
  • many Zoho apps use a lot of common Alt+ keys.

Thanks for the additional data!

With the proviso that I don't know much about the topic so I may be completely wrong, it seems while the Alt keys do present a fingerprinting risk it would require significant intentional interaction between a user and a website beyond just browsing. It seems as though the user would have to specifically press the Alt key, which a user probably wouldn't do unless they're trying to access an alt+hotkey (which wouldn't work) or type a non A-Z character into an input field, at which point a script could theoretically guess anyway that the user had a non-standard keyboard layout that can easily output non-A-Z characters and try to do more nefarious things like try to fingerprint users' typing speed, patterns, etc.

I think very common non-english characters like accented vowels and umlats expose as Alt combinations. You're correct that if a user types these quickly and easily it does give a good guess that the user has a non-standard keyboard layout. And you're also correct that we aren't defending against what I might call 'aggressive active fingerprinting' like profiling a user's mouse/keyboard behavior or running performance benchmarks against their hardware.

In light of the above I would kindly request you to re-consider the disabling of Alt+ hotkeys, for the time being, by making this feature opt-in or at least opt-out via an about:config flag.

We have strongly resisting creating opt-outs of individual resist fingerprinting features. If you set such a flag, you would the only or one of the only people whose browser fingerprint is [all of resist fingerprinting except a different keyboard layout]. We would have made you unique instead of giving you a crowd to blend into. That's quite bad.

Instead what we want to do is give users the option to disable all of resist fingerprinting on individual top level domains of their choosing. We don't have a timeline for this work right now however.

Thanks Tom, that's a very helpful explanation. I think Firefox's anti-fingerprinting efforts are great and very important work (though it might end up being a never ending arms race battle against advertisers). But it may be nice if a more conservative version of resist-fingerprinting that doesn't break any web functionality could become a Firefox default in future, which would help competitively differentiate FF further from other browsers (while also increasing the size of the resistFingerprinting 'crowd' to blend into).

Until that day, you're right, whitelisting domains to get full access to fingerprinting may be a more robust compromise than individual toggles.

Just want to point out it doesn't appear limited to Alt+ combinations. On the standalone JS hotkeys demo, one could observe neither Shift+ and Ctrl+ combinations get detected – only the non-modifier key gets detected (Ctrl+S → s, Shift+S → s). Funny the jquery demo detects Shift+ and Ctrl+. I've found this with an in-browser remote desktop service I have to occasionally use in my job – I wasn't able to log in until I've found I could type only small-caps and Ctrl+C/Ctrl+V (for Copy/Paste) doesn't appear to work. It would be really nice if one could turn RFP off for specific domains.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.