[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25750 [Applications/Tor Launcher]: update Tor Launcher for ESR 60
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs