[tor-bugs] #15646 [Tor Browser]: KeyboardEvent may allow fingerprinting of keyboard layout

[Tor Bug Tracker & Wiki]

#15646: KeyboardEvent may allow fingerprinting of keyboard layout
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  arthuredelstein
  cypherpunks            |     Status:  needs_revision
         Type:  defect   |  Milestone:
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  ff38-esr, tbb-fingerprinting, tbb-5
  Browser                |  .0a-highrisk, TorBrowserTeam201507R,
   Resolution:           |  GeorgKoppen201507R
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:23 gk]:

 > This looks better now. But we should give default values for `altKey`
 and `ctrlKey` as well (maybe even `metaKey`, too?) as not doing so might
 reveal the underlying keyboard layout (or maybe better: it might exclude
 possible keyboard layouts) as well:
 >
 > German keyboard layout
 >
 > {{{
 > event = keydown
 > key = |
 > charCode = 0
 > which = 220
 > code = Backslash
 > keyCode = 220
 > location = 0
 > altKey = true
 > ctrlKey = true
 > metaKey = false
 > shiftKey = true
 > }}}

 I think you're right that we need to spoof the ALT key state. (I've done
 so in the new patch.) But I'm not so sure about the META and CTRL keys --
 aren't these only used for non-printing commands? Correct me if I'm wrong.

 > Two nits:
 >
 > {{{
 > // KEY and SHIFT Assign
 > }}}
 > s/Assign/assign
 >
 > {{{
 > #define KEY_INTERNAL(key, code, keyCode, shift)                    \
 > }}}
 > It seems you wanted to align the backslashes but forgot one whitespace
 here?

 Thanks. I've fixed both nits.

 > Re: comment:6 I think the approach is okay. Could you take care of
 filing the new ticket you mentioned there?

 Here it is: #16678.

 > And a new ticket about investigating the possible initialization race
 Mike mentioned (or maybe you are already sure that can't bite us?)?

 I've added a mutex to createKeyCodes which will prevent any such race
 problem.

 Here's the new patch for review:

 https://github.com/arthuredelstein/tor-browser/commit/15646+2

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15646#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online