Opened 3 years ago

Closed 3 years ago

#17046 closed defect (fixed)

Event.timeStamp reveals startup time

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-linkability, TorBrowserTeam201509R
Cc: mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Experimenting with JS Events, I noticed the following:

If I open a web page's console in standard Firefox and enter
new Event("asdf").timeStamp
it returns a number like
1442000361118206.

This corresponds to the number of microseconds since the epoch. I confimed this result by entering:

window.setInterval(() => console.log(new Event("asdf").timeStamp), 1000)

and it prints out

1442000426991504
1442000427990600
1442000428989561
1442000429989980
1442000430990465
1442000431990790
1442000432989823
1442000433989783
...

This violates the web standard, which specifies milliseconds since the epoch: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-Event-timeStamp

Tor Browser gives similar result, but rounded to the nearest 100 microseconds, because of TBB's #1517 patch.

In any case, that's not the usual way to use Events. A more typical usage is:

window.addEventListener("mousedown", e => console.log(e.timeStamp))

If I click the mouse once per second (by listening to a clock) I get:

1028609
1029641
1030609
1031641
1032617
1033609
1034601
1035601
...

which indicates that the results are expressed in milliseconds. The epoch, however, is defined differently. In this case it reveals the system startup time, which is a linkability issue.

Child Tickets

Change History (9)

comment:1 Changed 3 years ago by arthuredelstein

Keywords: TorBrowserTeam201509R added
Status: newneeds_review

It turns out that if I set the 'dom.event.highrestimestamp.enabled' pref to true, then Event.timeStamp then returns the time in milliseconds equivalent to performance.now() (aka, in the main thread, navigationStart, the time when navigation to the page started). This pref activates the fairly new DOMHighResTimeStamp API:
https://w3c.github.io/hr-time/#dom-domhighrestimestamp

This behavior for Event.timeStamp seems much better.

To test this, enter

window.addEventListener("mousedown", e => console.log(e.timeStamp, new Event("asdf").timeStamp, performance.now()));

in the web console of any page, and then click once inside the page.

Here are results with different values for the 'dom.event.highrestimestamp.enabled' pref:

Pref value Output
Firefox false 9414030 1442009210662981 46220.675976000006
Firefox true 68844.30097800001 68844.634829 68844.65331200001
Tor Browser false 9643300 1442009439993700 7676700
Tor Browser true 7688400 7688400 7688400

It seems Mozilla intends to set this pref to 'true' by default, but first they want to get the timestamp directly from native OS events:
https://bugzilla.mozilla.org/show_bug.cgi?id=1026804

But for TBB we don't want precision in our timestamps anyway, so it looks OK if we set the pref to true. Here's a patch for review:

https://github.com/arthuredelstein/tor-browser/commit/17046

Last edited 3 years ago by arthuredelstein (previous) (diff)

comment:2 Changed 3 years ago by gk

Cc: mikeperry added
Status: needs_reviewneeds_information

Sounds good. I think we could test this at least in the alpha series. Mike, what do you think?

comment:3 Changed 3 years ago by arthuredelstein

I posted a question to Brian Birtles regarding this pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1026804#c13

comment:5 in reply to:  3 Changed 3 years ago by arthuredelstein

Replying to arthuredelstein:

I posted a question to Brian Birtles regarding this pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1026804#c13

Here is Brian's very helpful answer:
https://bugzilla.mozilla.org/show_bug.cgi?id=1026804#c14

comment:6 Changed 3 years ago by mikeperry

If all we're looking at is precision loss and maybe minor compat issues, I say we flip this now for stable and alpha. The linkability concern is rather large IMO, and trumps the apparently small risk of breakage (esp since Firefox has not seen any).

comment:7 Changed 3 years ago by mikeperry

One thing we should verify is that flipping this pref does indeed normalize the three timestamps for events for Windows, Linux, and Mac. It sounds like there is some risk that MacOS may not be normalized yet, depending on what the state of this pref was when FF38 was branched?

comment:8 in reply to:  7 Changed 3 years ago by arthuredelstein

Replying to mikeperry:

One thing we should verify is that flipping this pref does indeed normalize the three timestamps for events for Windows, Linux, and Mac. It sounds like there is some risk that MacOS may not be normalized yet, depending on what the state of this pref was when FF38 was branched?

I have now tested
https://arthuredelstein.github.io/tordemos/event-timestamp.html
with TBB 5.0.2 on Windows, Ubuntu, and OS X.

On all platforms, with the pref disabled, I get results like:

evt.timeStamp: 208597200
new Event('').timeStamp: 1442351957753400
performance.now(): 151700

If I enable the pref, I get:

evt.timeStamp: 204900
new Event('').timeStamp: 204900
performance.now(): 204900

comment:9 Changed 3 years ago by mikeperry

Resolution: fixed
Status: needs_informationclosed

Ok, I flipped this pref for 5.0.3 and 5.5a3.

Note: See TracTickets for help on using tickets.