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.
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.
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. If code cannot be shared, at least UI designs can be.
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