On Thu, Feb 01, 2018 at 10:01:00AM +0000, Georg Koppen wrote:
Matthew Finkel:
Hi All,
Apologies for the delay in sending this. Attached (or below) is the proposal for migrating the TorLauncher legacy extension to WebExtension. The main problem with directly moving TorLauncher to using WebExtensions is the two Extensions APIs are not 1-to-1. There was significant functionality previously available that is not available with WebExtensions. In particular these involve launching a child process and controlling it. This is a primary objective of TorLauncher, so we needed an alternative.
As a result, this proposal takes a mixed approach. Part of the functionality of TorLauncher will remain as an extension and the remaining functionality will be directly implemented into Tor Browser.
From the mobile/Android perspective, TorLauncher is a strange
requirement at this moment. On Android, Orbot controls and configures tor, and external Apps cannot configure tor which is the purpose of TorLauncher. In the future, we may prefer another design and integration, providing a better user experience.
Although the proposal is long, it is mostly documenting the extension's existing functionality.
Some comments to this proposal (although that's a bit harder with an attached proposal :) ):
Noted :) I'll in-line the file next time.
- What speaks against the plan Arthur brought up with respect to the
Torbutton proposal, to do a step-wise migration/adaptation? It seems we could follow that strategy as well with TorLauncher, no?
I support this, in general, and it is a good process for desktop, but I have two thoughts on this:
1) This limits Tor comm-central support - they'll need do the same within their builds, too.
2) This doesn't work on mobile, so we'll need another solution there.
- Regarding your backend rewriting plans, I am not sure yet why we want
to rewrite it in C++ and want to put the controller under netwerk/protocol? At any rate before we start with that endavour we should talk to the Mozilla folks if they'd need similar functionality for integrating tor and if so, how they would see us or whoever is going to write it actually do it.
Rewriting the controller in C++ allows for much better testing and easier sharing between desktop and android. Firefox for Android does not use XPCOM (except in rare situations), so C++ allows us to add add a XPCOM service on desktop and JNI wrapper on Android.
I don't currently believe a Tor controller in JS will work on Android at all.
- To answer the mobile questions: yes, the original plan (and current
one) was to launch and fully control an own tor service, not relying on an external app as this would match closely what we do on desktop. Now, if there is something smarter we should do on the mobile side which delivers the same features AND the same user experience AND the same security properties let's do it. Feel free to investigate that propose and propose changes to the original and current plan.
Yes, thanks for clarifying, we'll investigate this.
- I think we should pick up the sandboxing parts separately as they
might need an own proposal and result into something quite different from what we have today. See the discussion that got started with https://lists.torproject.org/pipermail/tbb-dev/2017-May/000548.html. Actually, it would be worth getting funding for that specific project I think. Alas, this has not happened yet.
Yes, funding would be great (I'm not expecting we'll solve all-the-problems right now).
Thanks for the feedback, Matt