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.
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- Georg Koppen added TorBrowserTeam201808R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff60-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::task in Legacy / Trac labels
added TorBrowserTeam201808R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff60-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::task in Legacy / Trac labels
- Author Developer
More tickets for 7.0.
Trac:
Keywords: N/A deleted, tbb-7.0-must added - Author Developer
Getting more tickets on our alpha radar.
Trac:
Keywords: tbb-7.0-must deleted, tbb-7.0-must-alpha added - Author Developer
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- Author Developer
Thanks, moving to esr59.
Trac:
Status: needs_review to assigned
Keywords: TorBrowserTeam201705R, tbb-7.0-must-alpha deleted, N/A added - Author Developer
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- Author Developer
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 - Author Developer
Marked legacy/trac#26604 (moved) as a duplicate. Mark mentioned in legacy/trac#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- Author Developer
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 missingthis.
in front of them, but I think the global JS object isthis
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 missingthis.
in front of them, but I think the global JS object isthis
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 usesthis.mSpoofEnglish
everywhere:https://github.com/arthuredelstein/tor-browser/commit/21787+2
- Author Developer
Fixed with commit 7150252e on
tor-browser-60.1.0esr-8.0-1
, thanks everyone!Trac:
Status: needs_review to closed
Resolution: N/A to fixed - Author Developer
https://bugzilla.mozilla.org/show_bug.cgi?id=1492587 is the upstream bug.
- Trac closed
closed
- Trac moved from legacy/trac#21787 (moved)
moved from legacy/trac#21787 (moved)
- Trac added Fingerprinting label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label