[tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60

[Tor Bug Tracker & Wiki]

#25750: update Tor Launcher for ESR 60
--------------------------------------------+------------------------------
 Reporter:  mcs                             |          Owner:  brade
     Type:  defect                          |         Status:  needs_review
 Priority:  Very High                       |      Milestone:
Component:  Applications/Tor Launcher       |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201805  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------
Changes (by sysrqb):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:21 sysrqb]:
 > And, indeed, TorLauncher throwing the exception (and nothing catching
 it) has exactly the result we want. By this, I mean it "disables Tor
 Launcher" and Tor Browser fails closed (assuming there aren't any proxy-
 bypass vulns, etc). We should have a better user experience in this
 situation, but I'm not sure how we should do that yet.
 >

 Although I agree with what I said, it's a terrible UX for users, so we
 should tell the user (somehow) that Tor Browser is in an undefined state.
 The only other option I see is we get rid of prefs.js entirely and somehow
 make sure all get...Prefs() calls use the correct default prefs.

 >
 > > A bonus is that we should be able to use the logging module inside
 `loadDefaultPreferences()` and related code.
 > >
 >
 > Yes, that would be a bonus, but that is difficult to do correctly
 without moving around more logic because there's a cyclic dependency here.
 Within `TLLoggerInternal._init()` we get the default prefs for `LogLevel`
 and `LogMethod`. If we want logging capability while we load the default
 prefs then we must initialize `TLLoggerInternal` first.
 >
 > I decided against moving around the code, and instead I left the
 `getIntPref()` calls as-is. This means the log level and log method are
 not set by the prefs.js value.
 >

 Similar to what was mentioned above. I worry about this situation, but as
 long as we're careful about keeping prefs.js and the getIntPrefs() calls
 synchronized, this shouldn't be a problem.

 > > BUT: the date format generated by the new code is a lot different than
 what we had before. Can you see if we can maintain the same format?
 > > Old: `5/9/18, 21:06:51.000 [NOTICE] Bootstrapped 100%: Done`
 > > New: `May 9, 2018 at 9:06:17 PM UTC.323 [NOTICE] Bootstrapped 100%:
 Done`
 > >
 >
 > Ah, good catch. I...missed that. The problem here is Firefox now formats
 the date/time according to the configured locale. We do have the option of
 hard coding the date/time format, but that is not the direction Mozilla
 are going in with respect to handling date/time format.

 Right, so we have a few options and available formats, from what I see.
 The built-in formats do not play nicely with appending the milliseconds at
 the end, because some locales use 12-hour clocks and have AM/PM suffix,
 plus some add the timezone. We'd need additional logic for detecting this.
 The four built-in formats for en-US are (with milliseconds appended):

 {{{
 dateStyle: "long", timeStyle: "long"
 May 11, 2018, 8:45:58 PM UTC.436

 dateStyle: "short", timeStyle: "long"
 5/11/18, 8:45:58 PM UTC.436

 dateStyle: "long", timeStyle: "short"
 May 11, 2018, 8:45 PM.436

 dateStyle: "short", timeStyle: "short"
 5/11/18, 8:45 PM.436
 }}}

 I'd like feedback about the best direction we should go with these.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25750#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online