investigate window.requestIdleCallback() for possible timing leaks
The window.requestIdleCallback() API is available as of Firefox 55. We should determine whether it may be used to learn too much about the performance of the user's computer/device, or if there are other timing leaks we want to avoid. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1314959
https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API
If necessary, we can disable this feature by setting dom.requestIdleCallback.enabled to false.
Activity
(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 likestd::max(mDeadline - performance->Now(), 0.0), andmDeadlineis 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, butperformance->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, sinceperformance->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 betweenrequestIdleCallbackand 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.)
A thing to think about. While we don't have ServiceWorkers yet I wonder whether the following assumption would still hold
// If there's no window, we're in a system scope, and can just use // a high-resolution TimeStamp::Now(); auto timestamp = TimeStamp::Now() - TimeStamp::ProcessCreation(); return std::max(mDeadline - timestamp.ToMilliseconds(), 0.0);and whether the direct use of
TimeStamp::Now()would be an issue here. However, looking at the implementation in https://bugzilla.mozilla.org/show_bug.cgi?id=1404652 this does indeed be only exposed to the system context. Thus, we should be fine here.
While acat is busy doing his/her thing ... https://trac.torproject.org/projects/tor/ticket/26606 - what's the analysis on this one
Recent reports are that it's starting to break sites (edit: if disabled), mainly images