[tor-bugs] #2876 [Tor bundles/installation]: Enable arbitrary delays on keypress event delivery in TorBrowser

[Tor Bug Tracker & Wiki]

#2876: Enable arbitrary delays on keypress event delivery in TorBrowser
--------------------------------------+-------------------------------------
 Reporter:  mikeperry                 |          Owner:  mikeperry
     Type:  enhancement               |         Status:  new      
 Priority:  normal                    |      Milestone:           
Component:  Tor bundles/installation  |        Version:           
 Keywords:                            |         Parent:  #2871    
   Points:                            |   Actualpoints:           
--------------------------------------+-------------------------------------
 Apparently firms are using typing cadence to fingerprint users:
 http://arstechnica.com/tech-policy/news/2010/02/firm-uses-typing-cadence-
 to-finger-unauthorized-users.ars

 At first, I thought we wanted to solve this by providing randomized high-
 res timing information to JS Date() because this would also help against
 fingerprinting the computational resources of a user, but I've since come
 to my senses. This will likely break the web all over the place (online
 video buffering, seek, and playback, synchronized animation, online
 games). Also, computational fingerprinting can be amortized over long
 periods of time in the background using WebThreads. There's not much we
 can do about that.

 So instead, let's focus on what the fingerprinting firms are focusing on.
 Let's alter Firefox keypress event delivery so that the DOM does not get
 any keypress information for a randomized jitter of something like
 0-500ms. Since most users type on the order of 2-4 characters per second
 (20-40WPM), an avg of 250ms delay should be sufficient to obfuscate this.

 However, we need to think carefully about the distribution of this delay:
 uniform may be good enough, but is a shape-shifting meta-distribution
 better?

 Also, we should think at which level we want to introduce this delay. It
 could just be delay to the DOM, so the user does not even notice it while
 using forms, but this may introduce a way for AJAX sites to repeatedly
 submit their forms in the background to measure how many characters tend
 to be accumulating per second.

 Based on http://en.wikipedia.org/wiki/Keystroke_dynamics, it sounds like
 the key properties we need to obscure is flight time and dwell time, and
 that character rate of formfill won't be as useful.
 However, if we can also handle formfill it without impacting user
 experience, maybe we should.

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