[tbb-dev] Tor Browser TorLauncher Proposal

[Matthew Finkel]

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.

> 
> 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?

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.

> 
> 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.

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.

> 
> 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.

Yes, thanks for clarifying, we'll investigate this.

> 
> 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.

Yes, funding would be great (I'm not expecting we'll solve
all-the-problems right now).

Thanks for the feedback,
Matt