[Whonix-devel] [Tails-dev] [tbb-dev] future of tor-launcher? - Firefox XPCOM / XUL based add-ons deprecation

anonym anonym at riseup.net
Thu Jan 26 15:48:00 CET 2017

Mark Smith:
> On 1/10/17 5:27 AM, anonym wrote:
>> Michael Carbone:
>>> The move away from XUL could be an opportunity to address this by
>>> building a more generic solution that could be used by the increasing
>>> number of tor-powered applications/environments, such as onionshare,
>>> ricochet, tails, qubes, subgraph, etc., in addition to tor browser and
>>> tor messenger.
> We talked about this a little bit yesterday during our Tor Browser team
> meeting on #tor-dev.
> The tight integration of Tor Launcher within the browser has been a big
> win for both user experience and for maintenance of the launcher and
> configuration code.

Fully understood.

> Our current plan for Tor Browser is to migrate Torbutton and Tor
> Launcher to the WebExtensions APIs, extending and adding new APIs as
> needed (and hopefully Mozilla will help us). See
> https://trac.torproject.org/projects/tor/ticket/17248.

Yeah, I've seen it. Like I said in the other sub-thread, this would still work for Tails if there was an option to emulate "standalone XUL application"-mode by simply suppressing the browser window.

>> Indeed! In Tails we have a ticket and blueprint tracking something like
>> this:
>>     https://labs.riseup.net/code/issues/10491
>>     https://tails.boum.org/blueprint/network_connection/
>> Of course, our configuration tool would also include OS-level stuff, but
>> I guess SubgraphOS/Qubes/Whonix would also be interested in that. At
>> least it'd be nice if code could be shared (e.g. we can import the Tor
>> configuration parts via a module and use the same  in our application).
>> Bonus if it's written in Python, building on the ecosystem of
>> Tor-related project we already have there (primarily stem).
>> I expect that some Tails people attending the Tor dev meeting in March
>> might be interested in discussing this.
> I think it is definitely worthwhile to talk more about this.

Let's do it then!

> If code cannot be shared, at least UI designs can be.

Absolutely! If it is not already stated as a goal that this new configuration tool would design the parts about Tor configuration the same way as Tor Launcher (or whatever) does for the vanilla Tor Browser. 

> It is also worth noting that Yawning created a new launcher/updater for
> Linux as part of his Sandboxed Tor Browser Project (it uses go, Gtk+ 3,
> and libnotify).
> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux

Interesting, but I wonder how much of this launcher that is about setting up the sandboxes -- my fear is that it simply is designed for something else than what we want. Any way, I haven't looked at it, I'm just speculating. :)

However, the need for a standalone Tor Launcher-like application is not limited to Tails. Clearly Whonix wants one since Patrick started this topic, and I could see e.g. OnionShare, and non-mozilla bundles (that cannot use your WebExtension) wanting to use something like that. It feels a bit odd to me if they would depend on e.g. Tor Browser, which currently is the case for e.g. OnionShare.


More information about the Whonix-devel mailing list