Opened 9 years ago

Closed 8 years ago

#2876 closed enhancement (duplicate)

Enable arbitrary delays on keypress event delivery in TorBrowser

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Firefox Patch Issues Version:
Severity: Keywords:
Cc: g.koppen@…, tagnaq@…, lunar@… Actual Points:
Parent ID: #3059 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 9 years ago by nickm

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.

comment:2 Changed 9 years ago by gk

Cc: g.koppen@… added

comment:3 in reply to:  1 ; Changed 9 years ago by 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.

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.

comment:4 in reply to:  3 Changed 9 years ago by mikeperry

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..

comment:5 Changed 9 years ago by tagnaq

Cc: tagnaq@… added

comment:6 Changed 9 years ago by mikeperry

Points: ?

I am back to thinking that timestamp binning may be the better approach. At least, I think it is the one to fix first, since it may actually not break people's experience as much in the strange new world of the HTML5 future.

comment:7 Changed 9 years ago by mikeperry

Component: Tor bundles/installationTor Browser

comment:8 Changed 9 years ago by lunar

Cc: lunar@… added

comment:9 Changed 9 years ago by mikeperry

Parent ID: #2871#3059

comment:11 Changed 9 years ago by mikeperry

Bah. The open source implementation just gives keypress timestamps in milliseconds. They don't even measure impact duration, and no ML is done on the resulting timestamps in their code.

Pretty weaksauce.

comment:12 Changed 8 years ago by mikeperry

Points: ?
Resolution: duplicate
Status: newclosed

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 instead.

Note: See TracTickets for help on using tickets.