[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16678 [Applications/Tor Browser]: Enhance KeyboardEvent fingerprinting protection for unusual characters

#16678: Enhance KeyboardEvent fingerprinting protection for unusual characters
-------------------------------------------------+-------------------------
 Reporter:  arthuredelstein                      |          Owner:  sysrqb
     Type:  enhancement                          |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-fingerprinting,                  |  Actual Points:
  TorBrowserTeam201709                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 Replying to [comment:13 arthuredelstein]:
 > Replying to [comment:10 sysrqb]:
 > > I surveyed the different layouts shown on the QWERTY [0], QWERTZ [1],
 and AZERTY [2] pages on Wikipedia, and I documented (roughly) the
 different keys (attached). From this, the patch [3] contains 131 unicode
 characters, covering most Latin charset-based keyboard layouts.
 >
 > Thank you for the patch. I think this is a significant enhancement to
 our previous patch. I wrote some comments and suggested revisions on the
 github commit at
 > https://github.com/sysrqb/tor-
 browser/commit/52b021674c6885d30e851557b14a8d70b5702a75#diff-
 8e201eb85e7d7abe2bb6b78e12c5081aR411
 >

 Thanks for the review! There are still a few outstanding questions I need
 to answer. I'll improve the branch as much as possible before the
 deadline.

 > Additionally (though not necessarily for the deadline) I would suggest
 adding a comment for each key mentioning which keyboard layout each key
 came from. (All previous keys came from the US keyboard.) Once the
 annotations are added, it would be prudent to have another review to
 carefully check each of the mappings to make sure they are correct.

 Yes, agreed. I'll add these as I make changes, but there will likely be
 some that will need updating after the deadline.

 >
 > Could you also comment here for the record on AltGr vs Alt vs AltLeft?
 Is AltGr they expected modifier in KeyboardEvents from most modern
 keyboards? It doesn't seem to appear on my Mac, if I recall correctly.

 Complicated. On Windows, it seems AltGr (AltRight) is converted into two
 distinct keydown KeyboardEvents, one for key='Alt' and keyCode='AltRight'
 and a second event with key='Control' and keyCode='CtrlLeft', while in
 Gnome I see key='AltGraph' and keyCode='AltRight'. The Wikipedia page
 [WIKIALTGR] says the Option key on a Mac keyboard is similar, but I don't
 have a Mac availbale for testing so unfortunately I don't know how that
 translates into KeyEvents in the browser when using different keyboard
 layouts.

 [WIKIALTGR] https://en.wikipedia.org/wiki/AltGr_key

 >
 > > The patch falls back on code "IntlBackslash" and keycode 220, when a
 mapping does not exist for a key. Something unfortunate/annoying I found
 while working on this is that unicode provides more than one code for the
 same glyph (such as U+0110 (capital letter D with stroke) and U+00D0
 (capital letter eth) for Ð), so I am worried some keyboard
 drivers/platforms use different codes for characters that are visually the
 same, thus this patch may result in slightly strange behavior.
 >
 > I guess we can't do anything about that confusion, correct? Do you think
 it would somewhat to block the key codes or match them for those
 doppelganger characters?
 >

 I think it's better if every character codepoint is mapped to a key per
 language/locale. I was considering mapping all doppelgangers to the same
 key, but after our discussion this seems like the wrong behavior. Every
 doppelganger is coupled with a specific set of languages, if we add an
 explicit mapping for a character then it should be relative to that
 language. So, in the case of 'Ð', we can map U+0110 with (letter D with
 stroke) respect to its location on a Slovic keyboard, and we can map
 U+00D0 (letter Eth) to its location on the Norwegian or Finnish keyboard.

 > > The key-to-code mappings were decided by taking the results of the
 survey and choosing the most common keyboard key per character/symbol.
 There were many symbols that were in a unique location on different
 layouts, so I chose a key that seemed reasonable.
 >
 > That's an interesting shell one-liner. Could you post the instructions
 on what it does and how to reproduce it for future work? :)

 I'm adjusting the mappings so they are based on the locale that is most
 likely to use a key rather than mapping it based on the most common key
 used for that character across all the keyboard layouts. So, this one-
 liners, which counts the number of times a key is mapped to a specific
 location on the keyboard (used the file attached), will not be very useful
 in the end.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs