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 <[email protected]>): > 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! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
