Make sure exposing the calendar information does not leak the locale

Exposes a JS Intl API to get calendar information (https://bugzilla.mozilla.org/show_bug.cgi?id=1287503). We should make sure that this does not leak the locale or allows to narrow it down.

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

More tickets for 7.0.

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Getting more tickets on our alpha radar.

Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added

Moving the investigation tickets to higher priority.

Trac:
Priority: Medium to High

In ESR52, I confirmed in the code and by manual observation that this functionality is not exposed in content. The getCalendarInfo function can be used from chrome code like this:

const mozIntl = Components.classes["@mozilla.org/mozintl;1"]
                          .getService(Components.interfaces.mozIMozIntl);
let x = {};
mozIntl.addGetCalendarInfo(x);
let calendarInfo = x.getCalendarInfo();

The only place in ESR52 where this is done is in a test: https://dxr.mozilla.org/mozilla-esr52/source/toolkit/components/mozintl/test/test_mozintl.js

But this is not possible from a content script. So I think we should postpone this ticket to ff59-esr.

Trac:
Keywords: ff52-esr deleted, ff59-esr, TorBrowserTeam201705R added
Status: new to needs_review

Thanks, moving to esr59.

Trac:
Status: needs_review to assigned
Keywords: TorBrowserTeam201705R, tbb-7.0-must-alpha deleted, N/A added

Firefox 60 is the new ESR.

Trac:
Keywords: ff59-esr deleted, ff60-esr added

This API remains chrome-only. I think there's no intention to expose it to content. So I would suggest closing this ticket.

Trac:
Status: assigned to needs_review
Keywords: ff60-esr deleted, ff60-esr TorBrowserTeam201808R added

Replying to arthuredelstein:

This API remains chrome-only. I think there's no intention to expose it to content. So I would suggest closing this ticket.

Ugh, that took me quite some time... What do you mean with "chrome-only"? It seems content might be able to get a user to trigger the API via the <input> element, no? See https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-nightly/ for some examples: there is definitely a localization component that is exposed to content. Not sure if JS can made to access that directly but I bet that at least the resulting rendering differences might give a hint about a possible used locale. This is "no issue" for the Tor Browser alpha but only as our content policy hack breaks this feature. We are about to remove it, though.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1283384 and https://bugzilla.mozilla.org/show_bug.cgi?id=1329589 for some context.

Trac:
Status: needs_review to needs_revision
Keywords: ff60-esr TorBrowserTeam201808R deleted, ff60-esr TorBrowserTeam201808 added

Marked #26604 (moved) as a duplicate. Mark mentioned in #26604 (moved):

If necessary, we can set the dom.forms.datetime pref to false to remove support for these <input> types.

Additional relevant bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1337319 https://bugzilla.mozilla.org/show_bug.cgi?id=1399036 (enabling the feature by default on all builds).

Unfortunately I had somehow missed the use of mozIntl.getCalendarInfo(...) in the date-time picker code. :(

Here's a patch for review. It uses the "en-US" locale for the date/time picker when privacy.spoof_english == 2.

https://github.com/arthuredelstein/tor-browser/commit/21787

Trac:
Status: needs_revision to needs_review
Keywords: ff60-esr TorBrowserTeam201808 deleted, ff60-esr TorBrowserTeam201808R added

Just one nit:

-        this.mResetButton.style.visibility = "hidden";
+          this.mResetButton.style.visibility = "hidden";

There is no need to indent that piece of the code. I tested the patch on a Linux box. Waiting on a second review either by mcs/brade or by pospeselr.

Trac:
Cc: N/A to mcs, brade, pospeselr

Replying to gk:

Just one nit: {{{

•    this.mResetButton.style.visibility = "hidden";

•      this.mResetButton.style.visibility = "hidden";

}}} There is no need to indent that piece of the code. I tested the patch on a Linux box. Waiting on a second review either by mcs/brade or by pospeselr.

Thanks -- here a new version with that fixed:

https://github.com/arthuredelstein/tor-browser/commit/21787+1

r=brade, r=mcs This looks good to us and some quick testing shows that it works (at least for some examples on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).

At first I was worried that some occurrences of mSpoofEnglish were missing this. in front of them, but I think the global JS object is this in those places so the code is OK.

Replying to mcs:

r=brade, r=mcs This looks good to us and some quick testing shows that it works (at least for some examples on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).

At first I was worried that some occurrences of mSpoofEnglish were missing this. in front of them, but I think the global JS object is this in those places so the code is OK.

Thanks, good catch. I think it's better to make the this explicit. So I made a new version that uses this.mSpoofEnglish everywhere:

https://github.com/arthuredelstein/tor-browser/commit/21787+2

Fixed with commit 7150252e7a0213aeddfe3c0aed294aae4cfcb3b8 on tor-browser-60.1.0esr-8.0-1, thanks everyone!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

https://bugzilla.mozilla.org/show_bug.cgi?id=1492587 is the upstream bug.

closed

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