Provide JS with reduced time precision

To help reduce information available to fingerprinting, we should randomize or truncate the values returned from Date(), event.timeStamp, and interval timers. I've never thought this was a useful thing to do before, because Tor latency is high enough and variable enough that most machines using NTP should be well concealed within the noise.

However, bug #1261 (closed) brings up a good point about javascript being able to measure the time intervals of various things (such as typing, but really it could be anything) to produce a fingerprint.

Unfortunately, we may need Firefox support for this, unless their javascript engine has changed to allow hooking of the Date() object again.

added PearlCrescent201505R TorBrowserTeam201505R backport-to-mozilla component::applications/tor browser ff38-esr points::10 priority::high resolution::fixed status::closed tbb-fingerprinting-time-highres tbb-torbutton type::enhancement labels

Trac:
Description: To help reduce information available to fingerprinting, we should randomize the values returned from Date(). I've never thought this was a useful thing to do before, because Tor latency is high enough and variable enough that most machines using NTP should be well concealed within the noise.

However, but bug #1261 (closed) brings up a good point about javascript being able to measure the time intervals of various things (such as typing, but really it could be anything) to produce a fingerprint.

to

To help reduce information available to fingerprinting, we should randomize the values returned from Date(). I've never thought this was a useful thing to do before, because Tor latency is high enough and variable enough that most machines using NTP should be well concealed within the noise.

However, bug #1261 (closed) brings up a good point about javascript being able to measure the time intervals of various things (such as typing, but really it could be anything) to produce a fingerprint.

Unfortunately, we may need Firefox support for this, unless their javascript engine has changed to allow hooking of the Date() object again.

Trac:
Priority: normal to major

This seems like a research problem. Randomizing the values naïvely won't actually keep a clever program from getting a value for Date; it will just call Date 10 times and take the mean.

Instead, we could quantize Date(), and randomize the cutoffs between the quanta, so that the value of Date remains the same (say) for 3.3 seconds minus a value chosen uniformly at random from between .6 and 0. Would this break programs people need? Probably. Would this defeat cadence attacks? Who can say; that's the research problem.

We actually have to do this at a lower level than just Date(). DOM events have .timeStamp, and JS interval timers also have ms resolution...

Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A
Parent: N/A to #2871 (closed)

FYI, here is the Firefox bug corresponding to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=575230

Trac:
Cc: N/A to tagnaq@gmail.com

Rough guess here. Depends on how centralized the JS interpreters timesource is. It may be all over the place, and far from config settings to control it. Also, some testing of youtube and various HTML5 demo sites should be performed, especially those involving rendered graphics and synchronized animations.

Trac:
Points: N/A to 16
Description: To help reduce information available to fingerprinting, we should randomize the values returned from Date(). I've never thought this was a useful thing to do before, because Tor latency is high enough and variable enough that most machines using NTP should be well concealed within the noise.

However, bug #1261 (closed) brings up a good point about javascript being able to measure the time intervals of various things (such as typing, but really it could be anything) to produce a fingerprint.

Unfortunately, we may need Firefox support for this, unless their javascript engine has changed to allow hooking of the Date() object again.

to

To help reduce information available to fingerprinting, we should randomize or truncate the values returned from Date(), event.timeStamp, and interval timers. I've never thought this was a useful thing to do before, because Tor latency is high enough and variable enough that most machines using NTP should be well concealed within the noise.

However, bug #1261 (closed) brings up a good point about javascript being able to measure the time intervals of various things (such as typing, but really it could be anything) to produce a fingerprint.

Unfortunately, we may need Firefox support for this, unless their javascript engine has changed to allow hooking of the Date() object again.
Summary: Torbutton should randomize times from Date() to Tor Browser should provide JS with reduced time precision

Trac:
Component: Torbutton to Tor Browser

Trac:
Cc: tagnaq@gmail.com to tagnaq@gmail.com, lunar@debian.org

Trac:
Parent: #2871 (closed) to #3059 (moved)

Related to this, we will need to quantize interval timers as well. Not sure if we'll get that for free by quantizing time, or if it will be additional work. It probably will be additional work, in which case it will need to go in a new ticket.

Replying to mikeperry:

Related to this, we will need to quantize interval timers as well. Not sure if we'll get that for free by quantizing time, or if it will be additional work. It probably will be additional work, in which case it will need to go in a new ticket.

On one hand, changes in Firefox 5 interval timer code to support "clamping" may make this easier. On the other hand, what about that same information coming from CSS animations: https://developer.mozilla.org/en/CSS/CSS_animations

Some notes here:

Clamping does not help us. It is specific to nsGlobalWindow::SetTimeoutOrInterval().

DOMWorkers also have their own SetTimeout functions.

There are several different DOM events, each with their own implementation of the timeStamp field. They do not share a common implementation.

I think that if we're going to do it in the browser, we pretty much have to patch PR_Now(), or alter the code in about a couple dozen different places. It will be a big patch that is sure to generate conflicts...

We'll also want to allow actual animations to have high-res timing (so they don't get jerky), but we'll need to specially handle the JS interface: https://developer.mozilla.org/en/DOM/event/AnimationEvent

I think we need to stay in JS land for this one. I'm going to guess that in JS-land, this will take a couple of days to repeatedly experiment with and test.

Trac:
Summary: Tor Browser should provide JS with reduced time precision to Provide JS with reduced time precision
Component: Tor Browser to TorBrowserButton
Points: 16 to 10

See commentary in #2876 (closed) for guidance on granularity and approach.

Trac:
Cc: tagnaq@gmail.com, lunar@debian.org to tagnaq@gmail.com, lunar@debian.org, g.koppen@jondos.de

Trac:
Keywords: N/A deleted, backport-to-mozilla added

Firefox 15 added high resolution timer support. It's not net documented though, just a bugzilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=539095

Trac:
Cc: tagnaq@gmail.com, lunar@debian.org, g.koppen@jondos.de to tagnaq@gmail.com, lunar@debian.org, g.koppen@jondos.de, intrigeri@boum.org

Mike, can you update that bug please? https://bugzilla.mozilla.org/show_bug.cgi?id=575230

Perhaps also quote Brendan Eich and tell him, that you know Tor is part of the answer, but you as Tor Browser developer still require the feature, because...

Might be useful to introduce your position in all upstream bug tickets so the answer won't be: use Tor.

Trac:
Cc: tagnaq@gmail.com, lunar@debian.org, g.koppen@jondos.de, intrigeri@boum.org to tagnaq@gmail.com, lunar@debian.org, g.koppen@jondos.de, intrigeri@boum.org, adrelanos@riseup.net