[tor-bugs] #26605 [Applications/Tor Browser]: investigate window.requestIdleCallback() for possible timing leaks

[Tor Bug Tracker & Wiki]

#26605: investigate window.requestIdleCallback() for possible timing leaks
-------------------------------------------------+-------------------------
 Reporter:  mcs                                  |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-fingerprinting-time-highres,     |  Actual Points:
  ff60-esr, TorBrowserTeam201904                 |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by acat):

 (TLDR: don't see a way of using this as a high precision timer or to
 effectively measure device performance)

 The callback receives an object which via `.timeRemaining()` method
 returns a DOMHighResTimestamp, the number of ms until the 'idle period' is
 over. The cb function is supposed to do some work and stop when
 `.timeRemaining()` is 0.

 This `.timeRemaining()` is calculated like `std::max(mDeadline -
 performance->Now(), 0.0)`, and `mDeadline` is a default guess of 50ms
 which is then refined based on a couple of factors (like estimated time
 until some event needs to be processed). First I thought this could be
 used as a high precision timer, but `performance->Now()` has precision of
 100ms in RFP, so that's not possible. Most of the time consecutive calls
 to `.timeRemaining()` will have the same value, since `performance->Now()`
 only changes every 100ms. As a side effect, values of `.timeRemaining()`
 will be bigger with RFP because of this (e.g. if real performance->Now()
 is ..199, mDeadline is ...249 then with RFP `.timeRemaining()` will be
 149, while without RFP it would be 50).

 In any case, RFP should prevent using this as a high precision timer.
 Also, `.timeRemaining()` is quite noisy, so I don't see a way of using it
 for something like measuring time of other events processed between
 idlecallbacks. One could try to measure the times between
 `requestIdleCallback` and the actual callback is called, as a proxy of
 'idleness'. But I do not see how this would be more effective than just
 doing a benchmark to measure computer performance (e.g. running several
 tasks in workers, etc.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26605#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online