disable User Timing API in ESR60

In #16336 (moved), we disabled the User Timing API by setting dom.enable_user_timing = false. Support for this pref was removed as of Firefox 55; see https://bugzilla.mozilla.org/show_bug.cgi?id=1344669.

We should do patch Firefox to resurrect support for this pref or do something else to mitigate the fingerprinting potential of this feature.

added TorBrowserTeam201808R component::applications/tor browser ff60-esr owner::tbb-team priority::high resolution::fixed severity::normal status::closed tbb-fingerprinting-time-highres type::defect labels

Trac:
Keywords: TorBrowserTeam201806 deleted, TorBrowserTeam201807 added

Trac:
Cc: N/A to arthuredelstein

Bumping prio.

Trac:
Priority: Medium to Immediate

Trac:
Priority: Immediate to High

According to the patch, the following APIs were formerly disabled when dom.enable_user_timing was false:

   PerformanceEntryList getEntries();
   PerformanceEntryList getEntriesByType(DOMString entryType);
   PerformanceEntryList getEntriesByName(DOMString name, optional DOMString
     entryType);
   void clearResourceTimings();
   void setResourceTimingBufferSize(unsigned long maxSize);
   attribute EventHandler onresourcetimingbufferfull;
   void mark(DOMString markName);
   void clearMarks(optional DOMString markName);
   void measure(DOMString measureName, optional DOMString startMark, optional DOMString endMark);
   void clearMeasures(optional DOMString measureName);

Looking at https://dxr.mozilla.org/mozilla-esr60/source/dom/performance/Performance.cpp, I see that much of this is already disabled when privacy.resistFingerprinting = true:

• getEntries, getEntriesByType and getEntriesByName all return empty lists.
• mark and measure do nothing.

We should still check if setResourceTimingBufferSize(unsigned long maxSize) and performance.onresourcetimingbufferfull expose a fingerprinting vector or supercookie mechanism.

Trac:
Description: In #16336 (moved), we disabled the User Timing API by setting odm.enable_user_timing = false. Support for this pref was removed as of Firefox 55; see https://bugzilla.mozilla.org/show_bug.cgi?id=1344669.

We should do patch Firefox to resurrect support for this pref or do something else to mitigate the fingerprinting potential of this feature.

to

In #16336 (moved), we disabled the User Timing API by setting dom.enable_user_timing = false. Support for this pref was removed as of Firefox 55; see https://bugzilla.mozilla.org/show_bug.cgi?id=1344669.

We should do patch Firefox to resurrect support for this pref or do something else to mitigate the fingerprinting potential of this feature.

Move our tickets to August.

Trac:
Keywords: TorBrowserTeam201807 deleted, TorBrowserTeam201808 added

I examined the code for setResourceTimingBufferSize(...): https://dxr.mozilla.org/mozilla-esr60/rev/dd52b41d2b775e5c7261ce52795268b7670635fc/dom/performance/Performance.cpp#407 and for Performance::InsertResourceEntry(...): https://dxr.mozilla.org/mozilla-esr60/rev/dd52b41d2b775e5c7261ce52795268b7670635fc/dom/performance/Performance.cpp#413

When "privacy.resistFingerprinting" is true, InsertResourceEntry shortcuts. Therefore no entries are added, and performance.onresourcetimingbufferfull is never called, regardless of any past calls to setResourceTimingBufferSize(unsigned long maxSize). So I am satisfied that there isn't a fingerprinting vector of supercookie mechanism exposed by this API.

Trac:
Status: new to needs_review

Looks good to me, thanks.

Trac:
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201808R added
Status: needs_review to closed
Resolution: N/A to fixed

closed

moved to tpo/applications/tor-browser#26598 (closed)