On 2/18/14, 1:08 PM, anonym wrote:
> Ah, now I get it, thanks! I must admit that even though I read this I
> completely missed the actual point. I still thought we were going to try
> the standalone XUL approach, and that's what I did (as indicated by the
> new subject line in this thread). Sorry for the confusion.
>
> Luckily I think this misunderstanding may be good in the end as it made
> me investigate the standalone approach:
>
>> TL;DR: the standalone XUL application idea (whose difficulty has not
>> been asserted) was superseded by the "exit the browser right after the
>> Tor Lancher config screens, if a given envvar is set" one, since it
>> seemed way easier, and good enough for us.
>
> TL;DR: I think the standalone approach is better, and like to switch it.
The main reason we proposed the "exit browser after configuration"
solution was because we were not sure how much work it would be to
create a standalone XUL app. But you have already done the work. The
downside I see is that you will need to ship (and maintain) XULRunner.
But maybe you already need to do that for other reasons.
> Some notes on "exit the browser" vs standalone XUL approaches:
> ...
>
> * When it comes to upstream maintenance, the "exit the browser" and
> standalone XUL approaches are pretty similar, at least as long as
> Tor Launcher only deals with starting/configuring Tor, and do not
> interact with Firefox (e.g. add something to `prefs.js` that's
> relevant for Firefox, or whatever). Tor Launcher maintainers, is
> this the plan for the foreseeable future?
To support a pluggable transports (PT) Tor Browser bundle, we have added
an option to configure a default set of bridges. That option requires
setting preferences inside the browser so that Tor Launcher knows to
reconfigure the default bridges each time the browser is started (we
need to set the bridge configuration each time because they originate
from hidden Tor Launcher preferences which may be updated when a new
version of TBB is installed). This is also why we need to start tor
with DisableNetwork=1 when the "use default bridges" option is enabled:
so we can update the bridge configuration before tor starts its
bootstrap process. See:
https://trac.torproject.org/projects/tor/ticket/10418
I am not sure if the concept of default bridges is something you will
want for Tails in the future or not.
Another small consideration is that we (TBB developers) will probably
not test Tor Launcher as a standalone XUL application because we will
not be using it that way... so it is possible we will accidentally break
something that is needed in that mode. Of course we will try not to do so.
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
