Opened 12 months ago

Closed 2 months ago

Last modified 2 months ago

#26605 closed defect (fixed)

investigate window.requestIdleCallback() for possible timing leaks

Reported by: mcs Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-time-highres, ff60-esr, TorBrowserTeam201904
Cc: arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (16)

comment:1 Changed 12 months ago by arthuredelstein

Cc: arthuredelstein added

comment:2 Changed 12 months ago by gk

Priority: MediumImmediate

Bumping prio.

comment:3 Changed 12 months ago by gk

Priority: ImmediateHigh

comment:4 Changed 11 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:5 Changed 10 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:6 Changed 9 months ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201809 removed

Moving tickets to October

comment:7 Changed 8 months ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:8 Changed 7 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:9 Changed 6 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:10 Changed 5 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:11 Changed 4 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving remaining tickets to March.

comment:12 Changed 3 months ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:13 Changed 2 months ago 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.)

comment:14 Changed 2 months ago by gk

Resolution: fixed
Status: newclosed

Thanks!

comment:15 Changed 2 months ago by gk

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.

comment:16 Changed 2 months ago by Thorin

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

Last edited 2 months ago by Thorin (previous) (diff)
Note: See TracTickets for help on using tickets.