Enable arbitrary delays on keypress event delivery in TorBrowser
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.
Activity
Round-to-the-nearest-N-msec would probably obfuscate better than add-a-random-delay. (IOW, like a timed mix, but without reordering.)
I wonder if we can get source code out of academics doing this attack, and see how well our approaches normalize cadence. It'd probably be an easy publication, if anybody's interested.
Trac:
Cc: N/A to g.koppen@jondos.de
Replying to nickm:
Round-to-the-nearest-N-msec would probably obfuscate better than add-a-random-delay. (IOW, like a timed mix, but without reordering.)
Yeah, probably. Then the fingerprinting code would always see only bins of dwell time and bins of flight time. Certainly easier to reason about how effective it is than some crazy probability distribution, at least. Ideally, we'd make the bin width such that they end up with uniform person-density in them, which means we'd need stats on the avg dwell and avg pairwise flight time.
I wonder if we can get source code out of academics doing this attack, and see how well our approaches normalize cadence. It'd probably be an easy publication, if anybody's interested.
Possibly. In my experience, getting source code out of academics is like pulling teeth. It is one of the reasons I left academia. No one wants you to actually try to reproduce their results... But if we could manage to find someone willing to give us an implementation to test against, I am all for it.
-
Replying to mikeperry:
Replying to nickm:
Round-to-the-nearest-N-msec would probably obfuscate better than add-a-random-delay. (IOW, like a timed mix, but without reordering.)
Yeah, probably. Then the fingerprinting code would always see only bins of dwell time and bins of flight time. Certainly easier to reason about how effective it is than some crazy probability distribution, at least. Ideally, we'd make the bin width such that they end up with uniform person-density in them, which means we'd need stats on the avg dwell and avg pairwise flight time.
Actually, it may be that all bin-widths is well below what is a noticeable amount of delay, so maybe we need only one bin.
Except, this makes me realize we're still going to break HTML5 games that use keyboard input. Or at least make people wonder why they suck so bad at them when using this privacy mode..
Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, tagnaq@gmail.com-
Trac:
Parent: #2871 (closed) to #3059 (moved) -
More research papers are beginning to pop up about this. There's one at HotPETS 2011 (not yet on the web), and here's a few others: http://portal.acm.org/citation.cfm?id=1025016
http://www.isot.ece.uvic.ca/publications/behavioral-biometricsx/HAISA2008-%20Digital%20Fingerprinting%20Based%20on%20Keystroke%20Dynamics.pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.680&rep=rep1&type=pdf http://people.csail.mit.edu/edmond/projects/keystroke/keystroke-biometrics.pdf http://cs.unc.edu/~fabian/papers/fgcs.pdf
Open Source implementation (demo seems broke for me): http://narcvs.com/javascript/fingerprint/
Source is at (both use same underlying algorithm): http://narcvs.com/javascript/fingerprint/standalone http://plugins.jquery.com/project/Fingerprint
-
Two more timing/keystroke fingerprinting papers:
http://petsymposium.org/2011/papers/hotpets11-final8Chairunnanda.pdf http://w2spconf.com/2011/papers/jspriv.pdf
Closing this though, because event delay is a crazy idea. Plan is to do #1517 (moved) instead.
Trac:
Points: ? to N/A
Status: new to closed
Resolution: N/A to duplicate mentioned in issue #2934 (moved)
mentioned in issue tpo/applications/tor-browser#2934 (closed)
