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 :) ):
1) 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?
2) 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.
3) 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.
4) 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.
Georg