Opened 2 years ago

Closed 16 months ago

Last modified 16 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 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:2 Changed 2 years ago by gk

Priority: MediumImmediate

Bumping prio.

comment:3 Changed 2 years ago by gk

Priority: ImmediateHigh

comment:4 Changed 2 years ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:5 Changed 2 years ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:6 Changed 23 months ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201809 removed

Moving tickets to October

comment:7 Changed 21 months ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:8 Changed 20 months ago by gk

Keywords: TorBrowserTeam201812 added; TorBrowserTeam201811 removed

Moving our tickets to December.

comment:9 Changed 19 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:10 Changed 18 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:11 Changed 17 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving remaining tickets to March.

comment:12 Changed 16 months ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:13 Changed 16 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 16 months ago by gk

Resolution: fixed
Status: newclosed

Thanks!

comment:15 Changed 16 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 16 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 16 months ago by Thorin (previous) (diff)
Note: See TracTickets for help on using tickets.