[tbb-dev] Tor Browser TorLauncher Proposal

[Georg Koppen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20180201/c72db55a/attachment.sig>