[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26605 [Applications/Tor Browser]: investigate window.requestIdleCallback() for possible timing leaks
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs