Re: does accessKeyLabel expose user data?

For those on public-privacy who are just learning about this functionality (like me), I think this is the relevant section of the HTML Rec:

http://www.w3.org/TR/html5/editing.html#assigning-keyboard-shortcuts <http://www.w3.org/TR/html5/editing.html#assigning-keyboard-shortcuts>

(Chaals, if there’s a more recent draft from the a11y task force, please do let us know. It’s always useful to have the context of the feature under review.)

I’ve been trying to gather guidance on fingerprinting questions in this document:
 http://w3c.github.io/fingerprinting-guidance/ <http://w3c.github.io/fingerprinting-guidance/>
So let me try to apply that here. It looks like this would increase the active fingerprinting surface, but not the passive, and wouldn’t be cookie-like. That is, it would only reveal information to JavaScript running on the page (not in HTTP requests) and it seems like it doesn’t create persistent state, unless implementations expect that they would provide a page the same set of key combinations that it received on last load. But it certainly does seem to increase that surface: for any user with a non-UA/platform-standard keyboard or a non-UA standard set of custom key combinations, the page can remember the resulting combinations and use that to recognize the user later.

I imagine one potential mitigation (which I don’t think I would recommend) would be to allow a page to indicate that a key combination should be displayed, but never actually provide DOM access to it. The reasoning would be: there don’t seem to be any other use cases besides showing the user what the relevant key combination is on the button or in a documentation panel somewhere, so why provide access to it in JavaScript? Of course, we know from various CSS privacy issues in the past that affecting the rendering/layout of the page without revealing that to JavaScript running on the page is a challenge, if it’s possible at all. But would it make it easier for a browser or a researcher to detect that that kind of fingerprinting was going on?

Also, you could, as is done elsewhere in HTML5, include the fingerprinting vector to at least note that this feature increases the fingerprinting surface. You might also specify how a UA should behave if it decides that the user is particularly privacy conscious and can’t implement these unique keyboard shortcuts. What should a Tor Browser developer do? (I would guess: set accessKeyLabel to null, as if no keyboard shortcut has been assigned. The UA might still implement the suggested shortcut.)

The bug notes a separate concern, which I think is important, about the leakage of information about other open frames/pages. Separate from fingerprinting (information to aid in recognizing a returning user), it would be unexpected if a page can determine whether certain popular browser extensions are installed (because they register a set of shortcuts) or if other software on the computer which typically reserves keyboard shortcuts is installed. Also, it might allow leakage across origins, if a page can determine what other pages the user has open based on which keyboard shortcuts are already reserved. I would be particularly concerned if my employer’s timecard web page could ask and answer "Does this user have GMail open during work hours?” That would also make certain phishing attacks more effective.

Hope this helps,
Nick

> On Dec 9, 2014, at 6:45 PM, chaals@yandex-team.ru wrote:
> 
> Hi folks,
> 
> (sorry, I just managed to join the mailing list - I had thought it happened automatically. I'll introduce myself later…)
> 
> I have an action from the W3C HTML accessibility task force to ask you to look at bug 23614 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23614>, which suggests that accessKeyLabel might expose user information.
> 
> accesskey is an HTML attribute to provide a keyboard shortcut for a link, button, etc. It suggests a list of possible keys to use. But the browser decides what *actual* key combination to use, and exposes that through the accessKeyLabel property in the DOM.
> 
> For example consider a link written as <a href="foo" accesskey="f o 0">…
> 
> The browser may have reserved every combination based on the "f" and "o" keys, and decide to use ctrl-option-0 as the shortcut for that link. If it does things right, the link will then have a DOM attribute of accessKeyLabel with the value "ctrl-option-0".
> 
> The concern is that this enables fingerprinting, or determining something about what systems (especially extensions and assistive technology) the user has installed, which in turn exposes personal information about the user.
> 
> Is this a real problem we should consider?
> 
> cheers
> 
> Chaals
> 
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>