Georg: Patrick Schleizer:
Hi,
XPCOM / XUL based add-ons will be deprecated in Firefox. [1]
I've searched trac, mailing list, irc logs... I know you are aware of that, but haven't found your plan forward. Is there already one?
What are your plans regarding tor-launcher? Will tor-launcher be ported over as Firefox WebExtension? Is that even possible?
We investigated what we would need for porting the extensions over to Webextensions a while ago in https://trac.torproject.org/projects/tor/ticket/17248.
The current plan has not changed: we still plan to port our extensions over to the Webextensions framework. It might need some upstream changes which we would provide with own patches but we'll see.
Georg
I had some discussions with Mark and Linda at the Tor Summit about the various non-browser use-cases for tor-launcher, especially as a means to allow the user to enable bridges/transports via GUI.
There is currently no GUI for users to select bridges/transports for non-XUL tor project applications. The move to WebExtensions does not seem to improve the situation.
I was wondering if this is still something being considered, even in the longer term?
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.
For background there had been a previously aborted effort to write a python-based tor-launcher clone:
https://www.whonix.org/blog/connection-bridge-wizard
Michael
Unsubscribe
On Jan 9, 2017, at 11:22 AM, Michael Carbone michael@qubes-os.org wrote:
Georg: Patrick Schleizer:
Hi,
XPCOM / XUL based add-ons will be deprecated in Firefox. [1]
I've searched trac, mailing list, irc logs... I know you are aware of that, but haven't found your plan forward. Is there already one?
What are your plans regarding tor-launcher? Will tor-launcher be ported over as Firefox WebExtension? Is that even possible?
We investigated what we would need for porting the extensions over to Webextensions a while ago in https://trac.torproject.org/projects/tor/ticket/17248.
The current plan has not changed: we still plan to port our extensions over to the Webextensions framework. It might need some upstream changes which we would provide with own patches but we'll see.
Georg
I had some discussions with Mark and Linda at the Tor Summit about the various non-browser use-cases for tor-launcher, especially as a means to allow the user to enable bridges/transports via GUI.
There is currently no GUI for users to select bridges/transports for non-XUL tor project applications. The move to WebExtensions does not seem to improve the situation.
I was wondering if this is still something being considered, even in the longer term?
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.
For background there had been a previously aborted effort to write a python-based tor-launcher clone:
https://www.whonix.org/blog/connection-bridge-wizard
Michael
-- Michael Carbone
Qubes OS | https://www.qubes-os.org @QubesOS https://www.twitter.com/QubesOS
PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4
tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
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.
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.
Cheers!
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:
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.
Cheers!
-
anonym -
Jonathan Haack -
Mark Smith -
Michael Carbone