JS Date object reveals OS type

added component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-fingerprinting-locale tbb-fingerprinting-os type::defect labels

Trac:
Keywords: N/A deleted, tbb-fingerprinting added

This does not seem to be the case with Firefox. On Mac OS, Windows 7, and Ubuntu I always get this format: 3/26/2015, 3:02:40 PM Each of the systems I tested on are set for U.S. / English, so I guess that might be the difference. I did not spend a lot of time on it, but I quickly got lost reading src/builtin/Date.js and js/src/builtin/Intl.cpp.

Trac:
Cc: gk to gk, brade, mcs

Shot in the dark: might this have something to do with building without --without-intl-api on Mac and Windows?

Trac:
Summary: JS Date object reveals OS type to JS Date object reveals OS type (TBB specific)
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-os added

Replying to mcs:

This does not seem to be the case with Firefox. On Mac OS, Windows 7, and Ubuntu I always get this format: 3/26/2015, 3:02:40 PM Each of the systems I tested on are set for U.S. / English, so I guess that might be the difference. I did not spend a lot of time on it, but I quickly got lost reading src/builtin/Date.js and js/src/builtin/Intl.cpp.

I just tested in standard Firefox (presumably using the US English locale) by entering: [new Date().toLocaleFormat(), new Date().toLocaleString()] Ubuntu: Array [ "Thu 26 Mar 2015 19:32:43 GMT", "26/03/2015 19:32:43" ] OSX: Array [ "Thu Mar 26 12:35:24 2015", "3/26/2015, 12:35:24 PM" ] Windows 7: Array ["Thursday, March 26, 2015 12:34:50 PM", "3/26/2015, 12:34:50 PM"]

Replying to arthuredelstein:

I just tested in standard Firefox (presumably using the US English locale) by entering: [new Date().toLocaleFormat(), new Date().toLocaleString()] ...

I did not try toLocaleFormat() before but here is what I got using your same technique:

Ubuntu: Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ] OSX: Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ] Windows 7: Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]

So it seems that toLocaleFormat() is a problem in any case.

Replying to mcs:

Replying to arthuredelstein:

I just tested in standard Firefox (presumably using the US English locale) by entering: [new Date().toLocaleFormat(), new Date().toLocaleString()] ...

I did not try toLocaleFormat() before but here is what I got using your same technique:

Ubuntu: Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ] OSX: Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ] Windows 7: Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]

So it seems that toLocaleFormat() is a problem in any case.

Yes, it looks like my Ubuntu VM may be using en_GB for some reason. I'm updating the ticket description to mention new Date().toLocaleFormat().

Trac:
Description: Calls like new Date().toLocaleString() produce different Date formatting, depending on the platform.

Example from gk:

Mac: Wed Mar 25 ...
Win: Wednesday, March 25 ...
Linux: 3/25 ...

to

Calls like new Date().toLocaleFormat() produce different Date formatting, depending on the platform.

Example from mcs:

Ubuntu: Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ] OSX: Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ] Windows 7: Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]

Trac:
Description: Calls like new Date().toLocaleFormat() produce different Date formatting, depending on the platform.

Example from mcs:

Ubuntu: Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ] OSX: Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ] Windows 7: Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]

to

Calls like new Date().toLocaleFormat() produce different Date formatting, depending on the platform.

Results from mcs, calling [new Date().toLocaleFormat(), new Date().toLocaleString()]:

Ubuntu: Array [ "Thu 26 Mar 2015 03:43:35 PM EDT", "3/26/2015, 3:43:35 PM" ] OSX: Array [ "Thu Mar 26 15:38:55 2015", "3/26/2015, 3:38:55 PM" ] Windows 7: Array [ "Thursday, March 26, 2015 3:45:01 PM", "3/26/2015, 3:45:01 PM" ]

Resetting title to reflect that this is not TBB specific, and is present in stock Firefox.

Trac:
Summary: JS Date object reveals OS type (TBB specific) to JS Date object reveals OS type

Trac:
Cc: gk, brade, mcs to gk, brade, mcs, arthuredelstein

Spent some time looking at this and there doesn't seem to be a good fix. The root problem is that toLocaleFormat() is eventually calling strftime with a "%c" format, using the system dependent date/time locale format which obviously varies per platform.

Potential fixes that I see are:

call nsIDateTimeFormat to get a proper Unicode CLDR locale dependent date time string that's platform independent. The problem with this approach is that it introduces a dependency from the JS engine to the i18n library, which I expect would be frowned upon (and probably introduces another set of problems or two).
re-create the CLDR date time format strings in the JS engine. Introduces a lot of complexity to fix a relatively small issue, not to mention having a parallel locale system that needs to be maintained independently of the main one in the i18n library.
hard-code a single date time format string. While this would fix the underlying issue, it also causes the locale dependent date time output to be wrong for a large percentage of users, which can be quite bad (though it has the advantage of hiding the user's locale at this API surface, not sure if that's desirable in the end).
hard-code a set of locale based date time format strings keyed off the C++ std::time_get::date_order. Still results in a wrong locale date time format for many users, but not as many as option 3. It at least covers the fundamental issue of dmy vs mdy vs ymd etc, but doesn't handle proper date and time separators, 12/24 hour time, month/day/year indicator text, etc (though a reasonable guess can be made for most users). While not ideal, the output should at least be parsable for most users.
some variant of option 4 but also add a user preference to set a proper date time format string. Not a good user experience and provides an additional fingerprinting surface (and may also introduce another dependency from the js engine to the prefs system, though I didn't investigate this).
do some heuristic analysis of the output of strftime("%c") (with a static time) to make some inferences about what the platform date time format string is, and then massage from that into a standardized format string. Seems fragile and error-prone.

Unfortunately there don't appear to be good platform APIs on linux to get better locale information from the OS to do much better than option 4 (that I'm aware of anyway).

Trac:
Username: peterlinss
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normal

I think we can close this - unless you want to keep it open as a general date issues ticket

https://bugzilla.mozilla.org/show_bug.cgi?id=818634 - FF58+ deprecated toLocaleFormat
https://bugzilla.mozilla.org/show_bug.cgi?id=1409973 - fixes toLocaleString and Intl.DateTimeFormat

Replying to Thorin:

I think we can close this - unless you want to keep it open as a general date issues ticket

https://bugzilla.mozilla.org/show_bug.cgi?id=818634 - FF58+ deprecated toLocaleFormat

https://bugzilla.mozilla.org/show_bug.cgi?id=1409973 - fixes toLocaleString and Intl.DateTimeFormat

Yes, this got fixed upstream, thanks.

Trac:
Resolution: N/A to fixed
Status: new to closed
Keywords: N/A deleted, tbb-fingerprinting-locale added

closed

mentioned in issue #26146 (moved)

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

JS Date object reveals OS type

Child items ...

Activity