language info leaked by JS Date methods in Windows and Linux

In greg's test at http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html, the Date string ends up localized to the user's language.

We should scrub it or remove it most likely. See also #5922 (closed) for info on the relevant source code paths.

added component::applications/tor browser interview owner::tbb-team priority::high resolution::duplicate status::closed tbb-fingerprinting-locale tbb-firefox-patch type::defect labels

Trac:
Cc: N/A to g.koppen@jondos.de

Trac:
Keywords: N/A deleted, MikePerry201206 added

Trac:
Keywords: MikePerry201206 deleted, N/A added

Some additional stuff was exposed on this object in https://bugzilla.mozilla.org/show_bug.cgi?id=743843.

Trac:
Keywords: N/A deleted, interview added

Greg's test, mentioned above, produces the Date string not from an nsXPCException (as the ticket title claims), but from a line in the function log(txt) in the source file http://pseudo-flaw.net/tor/torbutton/torbutton-common.js, that contains the expression (new Date()).toLocaleString().

In any case, I have examined the Date string produced by this test under both US English and German versions of TBB, and also under computer locale and language set to both US English and German. In all cases, I see the same Date formatting: Date: Fri May 9 23:03:18 2014 which corresponds to the current UTC time.

So I think this bug no longer exists, and I would suggest that it can be closed.

I tested it under a german OS which gives me something like:

Date: Montag, 12. Mai 2014 09:36:21

So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

Trac:
Cc: g.koppen@jondos.de to gk

Replying to gk:

I tested it under a german OS which gives me something like: {{{ Date: Montag, 12. Mai 2014 09:36:21 }}} So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

Interesting. What OS did you test with?

OK, I can reproduce this on Ubuntu 14.04 LTS. In the web console, I can also generate localized strings with English-US: new Date().toLocaleString(); -> "Mon May 12 18:01:49 2014" new Date().toLocaleDateString(); -> "05/12/2014" vs German: new Date().toLocaleString(); -> "Mo 12 Mai 2014 18:04:56 UTC" new Date().toLocaleDateString(); -> "12.05.2014"

I'm not able to reproduce this on OS X.

Replying to arthuredelstein:

Replying to gk:

I tested it under a german OS which gives me something like: {{{ Date: Montag, 12. Mai 2014 09:36:21 }}} So, it seems the bug is not about revealing non-en(-US) TBB locales but about revealing non-en(-US) OS locales. And it is still there in the 3.6.1 series.

Interesting. What OS did you test with?

Windows 7. Seems my test Mac (10.6.8) is not affected by this problem either.

Here's a more extensive demo of the Date locale problem. http://jsbin.com/luririxo/1/watch?js,output

Trac:
Summary: nsXPCException leaks language info via Date string in exceptions to language info leaked by JS Date methods in Windows and Linux

I'm working on a patch for this. Question: Does it make sense to add a preference to turn on and off Date locale anonymization? Or is there another existing pref I should use? If we need a new pref, should it be called something like privacy.javascript.anonymize?

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Owner: mikeperry to tbb-team
Component: Firefox Patch Issues to Tor Browser

#13050 (moved) is a duplicate of this one.

See also #13019 (moved). As for prefs, we currently have extensions.torbutton.spoof_english, spoof_locale and spoof_language, but yes, we probably also want a native browser pref here. Something that clearly indicates this is for locale normalization/spoofing rather than just generic anonymization.

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-locale added

#15268 (moved) is a duplicate of this one.

Arthur: There is a bugfix in #13019 (moved) claiming to fix this bug (looking at the commit message) which is quite confusing. Even more, it does not affect this bug at all. So what's up with that? And how is #10284 (moved) related?

Trac:
Status: new to needs_information
Cc: gk to gk, arthuredelstein

Replying to gk:

Arthur: There is a bugfix in #13019 (moved) claiming to fix this bug (looking at the commit message) which is quite confusing. Even more, it does not affect this bug at all. So what's up with that?

Yes, I should have labeled the patch as #13019 (moved). I believe that patch does in fact fix the Date locale problem reported in this ticket, but it is confusing because the problem has nothing to do with the purpose of Greg's test. I propose closing this ticket as a duplicate of #13019 (moved), if you agree.

And how is #10284 (moved) related?

That looks like another duplicate to me, in the sense that I believe it is fixed by the same patch.

I have opened a ticket (#15299 (moved)) for regression tests for this patch so we can be sure it's working.

Ok, we track the effort with the locale leaks in #13019 (moved) which had the former patch. This is a duplicate of it then.

Trac:
Resolution: N/A to duplicate
Status: needs_information to closed

closed

mentioned in issue #6420 (closed)

mentioned in issue #13019 (moved)

mentioned in issue #13050 (moved)

mentioned in issue #15161 (closed)

mentioned in issue #15268 (moved)

mentioned in issue #15299 (moved)

mentioned in issue #17329 (moved)

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

mentioned in issue tpo/applications/tor-browser#15299 (moved)

mentioned in issue tpo/applications/tor-browser-bundle-testsuite#40047