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
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
