Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tail…

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The Tails public development discussion list
CC: Mike Perry, Mark Smith, Kathleen Brade
Assumpte: Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
18/02/14 10:56, intrigeri wrote:
> Hi,
>
> anonym wrote (18 Feb 2014 01:07:07 GMT) :
>> Sorry, but I don't understand the "exit the browser [...]" part. In the
>> way we intend to use the Tor Launcher in Tails there will be no browser
>> as it will run as a standalone XUL application.
>
> There seems to be some amount of misunderstanding here. As suggested
> earlier privately, you really want to read the beginning of this
> thread.


I assume the following quote is what you are talking about:

14/01/14 17:09, Kathleen Brade wrote (in email with Message-ID
<52D5614D.3090508@???>):
> Here is another idea: What if Tor Launcher presented its initial
> configuration dialogs and then exited after the user clicked
> "Connect"?


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.

Some notes on "exit the browser" vs standalone XUL approaches:

* Just to be clear: the code needed for the "don't start, only
configure Tor" use case is completely independent either approach.

* The *only* thing required to run Tor Launcher as a standalone XUL
application is an application.ini and the correct invocation of
xulrunner. In particular, no code changes are required inside Tor
Launcher's logic.

* At least the previous point is true for the Tails use case. To make
standalone Tor Launcher support *starting* *and* *owning* the Tor
process as well (i.e. without `TOR_CONFIGURE_ONLY=1`), I think some
more work is needed, since owning the Tor process means that it'll
terminate when Tor Launcher closes (i.e. immediately after it has
configured Tor in the standalone case). Since we don't need it, I
guess we wouldn't care, but fixing it should be pretty simple for
those that do.

* Actually the "exit the browser" approach will require one piece of
extra code, namely to exit the browser at the appropriate time if
`TOR_CONFIGURE_ONLY=1`. Actually, overloading that option with this
additional behaviour is pretty ugly and highly Tails-specific
(non-Tails users may want to set that option to configure their
system-wide Tor *and* have a browser afterwards). It'd make more
sense with yet another option, like `NO_BROWSER=1` or something
similarly weird. Otherwise we might just as well bake all
Tails-specific stuff into a `RUNNING_IN_TAILS=1`.

* 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?

* When it comes to Debian packaging, both are trivial to package. I
suppose that, if anything, Debian is more likely to ever package the
Firefox extension, but even that seems unlikely to me at this
point. Hence I guess we (Tails) will be effectively responsible for
it, so there's nothing in favour of either approach here then.

* The way I understand the "exit the browser" approach is that we'd
have Tor Launcher installed as an Iceweasel extension. However,
having it intalled in our default Iceweasel profile will not be
pretty so we'll have to generate yet another profile, with the added
complexity and maintaince burden of that.

* Relating to the previous point, nothing extra is required for the
standalone Tor Launcher to run it as a separate profile (starting it
will automatically create a profile in `.torproject/tor-launcher`).

Conclusion: if my analysis above is correct, and my assertions/questions
are the way I expect, then the standalone XUL approach is in fact
cleaner, simpler, more flexible, more portable (outside the Tails
context) and more maintainable than the "exit the browser" one. I can
see no disadvantage with it, now that the research has been done.
Therefore I think we should change the old plan and go with the
standalone XUL application approach instead.

Cheers!