Opened 8 years ago

Closed 3 years ago

#1517 closed enhancement (fixed)

Provide JS with reduced time precision

Reported by: mikeperry Owned by:
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: backport-to-mozilla, tbb-torbutton, tbb-fingerprinting-time-highres, ff38-esr, TorBrowserTeam201505R, PearlCrescent201505R
Cc: tagnaq@…, lunar@…, gk, intrigeri@…, adrelanos@…, arthuredelstein@… Actual Points:
Parent ID: Points: 10
Reviewer: Sponsor:

Description (last modified by mikeperry)

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

Child Tickets

Change History (32)

comment:1 Changed 8 years ago by mikeperry

Description: modified (diff)

comment:2 Changed 8 years ago by mikeperry

Priority: normalmajor

comment:3 Changed 8 years ago by nickm

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.

comment:4 Changed 7 years ago by mikeperry

Parent ID: #2871

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

comment:5 Changed 7 years ago by mikeperry

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

comment:6 Changed 7 years ago by tagnaq

Cc: tagnaq@… added

comment:7 Changed 7 years ago by mikeperry

Description: modified (diff)
Points: 16
Summary: Torbutton should randomize times from Date()Tor Browser should provide JS with reduced time precision

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.

comment:8 Changed 7 years ago by mikeperry

Component: TorbuttonTor Browser

comment:9 Changed 7 years ago by lunar

Cc: lunar@… added

comment:10 Changed 7 years ago by mikeperry

Parent ID: #2871#3059

comment:11 Changed 7 years ago by 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.

comment:12 in reply to:  11 Changed 7 years ago by mikeperry

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

comment:13 Changed 7 years ago by mikeperry

Component: Tor BrowserTorBrowserButton
Points: 1610
Summary: Tor Browser should provide JS with reduced time precisionProvide JS with reduced time precision

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.

comment:14 Changed 7 years ago by mikeperry

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

comment:15 Changed 7 years ago by gk

Cc: g.koppen@… added

comment:16 Changed 7 years ago by StrangeCharm

Keywords: backport-to-mozilla added

comment:17 Changed 6 years ago by mikeperry

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

comment:18 Changed 6 years ago by intrigeri

Cc: intrigeri@… added

comment:19 Changed 6 years ago by proper

Cc: adrelanos@… added

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.

comment:20 Changed 4 years ago by erinn

Component: TorBrowserButtonTor Browser
Keywords: tbb-torbutton added

comment:21 Changed 4 years ago by mikeperry

Keywords: tbb-fingerprinting-time-highres added

comment:22 Changed 4 years ago by mikeperry

Parent ID: #3059

comment:23 Changed 4 years ago by gk

Cc: gk added; g.koppen@… removed

comment:24 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein@… added

comment:25 Changed 3 years ago by mikeperry

Keywords: ff38-esr TorBrowserTeam201504R added

This turned out to be easier to do than I expected. Also, given http://arxiv.org/pdf/1502.07373v2.pdf (Aka "The Spy in the Sandbox"), we may want to do this sooner rather than later (ie for 5.0a1).

Here's a patch that should make all JS clock sources and event timestamps have 100ms resolution, except for keypress events, which should have 250ms resolution: https://gitweb.torproject.org/user/mikeperry/tor-browser.git/commit/?h=bug1517. It also clamps internal usage of DOMHighResTimestamps to 1 microsecond, to avoid internal sidechannels and other leaks.

Note that this patch does not alter event delivery or interval timer invocation in any way, as I expect that altering event delivery and timer invocation will break more things (especially twitch games and video/animation) than simply messing with Javascript's notion of wall-clock time. I chose 100ms resolution because it seemed like a very large granularity while still being on the edge of human perception. We'll need to test this on a bunch of Javascript games, HTML5 animation sites, and lots of HTML5 video, but hey, at least that will be fun! :)

We'll also want to keep a close eye on this for ff38-esr, as I bet more events/time sources were added since FF31.

comment:26 Changed 3 years ago by mikeperry

Status: newneeds_review

comment:27 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201505 added

comment:28 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201505R added; TorBrowserTeam201504R TorBrowserTeam201505 removed

comment:29 Changed 3 years ago by mcs

Keywords: PearlCrescent201505R added

comment:30 in reply to:  25 ; Changed 3 years ago by mcs

Replying to mikeperry:

Here's a patch that should make all JS clock sources and event timestamps have 100ms resolution, except for keypress events, which should have 250ms resolution: https://gitweb.torproject.org/user/mikeperry/tor-browser.git/commit/?h=bug1517. It also clamps internal usage of DOMHighResTimestamps to 1 microsecond, to avoid internal sidechannels and other leaks.

Kathy and I reviewed this and the changes look OK. It is hard to say what might break though.

One question: do you know how the ToMilliseconds() and ToMicroseconds() calls inside xpcom/ds/TimeStamp.h are exposed to web content? Is ToSeconds() exposed as well? If so, we should also reduce the resolution of values returned by ToSeconds().

comment:31 in reply to:  30 Changed 3 years ago by mikeperry

Replying to mcs:

Replying to mikeperry:

Here's a patch that should make all JS clock sources and event timestamps have 100ms resolution, except for keypress events, which should have 250ms resolution: https://gitweb.torproject.org/user/mikeperry/tor-browser.git/commit/?h=bug1517. It also clamps internal usage of DOMHighResTimestamps to 1 microsecond, to avoid internal sidechannels and other leaks.

Kathy and I reviewed this and the changes look OK. It is hard to say what might break though.

One question: do you know how the ToMilliseconds() and ToMicroseconds() calls inside xpcom/ds/TimeStamp.h are exposed to web content? Is ToSeconds() exposed as well? If so, we should also reduce the resolution of values returned by ToSeconds().

ToMicroseconds() is exported to content by window.performance.now(). I think ToMilliseconds the underlying call to obtain the timesource for nsDOMEvents (though at the moment I'm not 100% certain exactly what made me believe this, but some casual grepping shows that it is used everywhere in the codebase). I didn't touch ToSeconds() because its implementation is highly platform dependent, and it is only used in the animation code. It did not appear exposed directly to content.

I will verify all this with deeper inspection tomorrow.

comment:32 Changed 3 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

I looked into this more, and noticed one case where ToSeconds() was exposed to content. AnimationFrame events have an elapsedTime field. I truncated that timestamp to millisecond accuracy (though in reality, the timestamps were varying by as much as 20ms for me).

I didn't see any other leaks to content by either ToSeconds or ToMilliseconds.. I pushed this to tor-browser-31.7.0esr-5.0-1 for 5.0a1 as commit dcd5fcc102a3eb19c20013542fa3ca399db66da4.

Calling this 'fixed' for now, but I imagine we'll have a fun time testing everything and deciding what to do about breakage, and we'll want to revisit this for ff38-esr.

Note: See TracTickets for help on using tickets.