Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#31985 closed defect (fixed)

Check that Intl.RelativeTimeFormat does no leak the user agent locale

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff68-esr, tbb-fingerprinting-locale, TorBrowserTeam201910
Cc: Actual Points: 0.25
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description

https://bugzilla.mozilla.org/show_bug.cgi?id=1504334 is shipping the new Intl.RelativeTimeFormat interface.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RelativeTimeFormat has some more information about this feature which appeared live in Firefox 65

Child Tickets

Change History (2)

comment:1 Changed 2 months ago by gk

Actual Points: 0.25
Resolution: fixed
Status: newclosed

The feature got actually implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1270140.

We should be good here due to the work that landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1409973, where the locale of the JS runtime can be spoofed in a way that always en-US is given back if resist fingerprinting is enabled.

I double-checked that on Linux by modifying the MDN example a bit, so that the code falls back to the default locale:

var rtf1 = new Intl.RelativeTimeFormat({ style: 'narrow' });

gives me a localized value if I don't have spoofing enabled but correctly give en-US values back otherwise.

A cursory code inspection showed as well that the locale of the JS context is queried (https://searchfox.org/mozilla-esr68/source/js/src/builtin/intl/RelativeTimeFormat.cpp#208) which points to the JS runtime (https://searchfox.org/mozilla-esr68/source/js/src/vm/JSContext.h#262), which in turn gets the proper default locale in https://searchfox.org/mozilla-esr68/source/js/xpconnect/src/XPCLocale.cpp#117.

So we are good here.

comment:2 Changed 2 months ago by gk

Keywords: ff68-esr added
Note: See TracTickets for help on using tickets.