Re: [tor-bugs] #15473 [Applications/Tor Browser]: JS Date object reveals OS type

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#15473: JS Date object reveals OS type
--------------------------------------+--------------------------
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-fingerprinting-os     |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------
Changes (by peterlinss):

 * severity:   => Normal


Comment:

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

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15473#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs