Opened 4 years ago

Last modified 5 months ago

#15473 new defect

JS Date object reveals OS type

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-os
Cc: gk, brade, mcs, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arthuredelstein)

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" ]

Child Tickets

Change History (11)

comment:1 Changed 4 years ago by arthuredelstein

Keywords: tbb-fingerprinting added

comment:2 Changed 4 years ago by mcs

Cc: brade mcs 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.

comment:3 Changed 4 years ago by mikeperry

Keywords: tbb-fingerprinting-os added; tbb-fingerprinting removed
Summary: JS Date object reveals OS typeJS Date object reveals OS type (TBB specific)

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

comment:4 in reply to:  2 ; Changed 4 years ago by arthuredelstein

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"]

comment:5 in reply to:  4 ; Changed 4 years ago by 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.

comment:6 in reply to:  5 Changed 4 years ago by arthuredelstein

Description: modified (diff)

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().

comment:7 Changed 4 years ago by arthuredelstein

Description: modified (diff)

comment:8 Changed 4 years ago by mikeperry

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

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

comment:9 Changed 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:10 Changed 2 years ago by peterlinss

Severity: Normal

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:
1) 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).
2) 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.
3) 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).
4) 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.
5) 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).
6) 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).

comment:11 Changed 5 months ago by Thorin

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

Note: See TracTickets for help on using tickets.