[tbb-dev] [Proposal] Tor Browser Quickstart - Call for Comments

[Antonela D]

Thanks folks for the feedback on the proposal! All your comments are
appreciated and express a real need from our ecosystem while embedding tor
in your apps.

I'll summarize a few takeaways here:

- To be clear, Tor Launcher will not be removed. Tor Browser will have its
own UI for connecting, giving us more flexibility to develop censorship
detection and provide bridges to reach the internet. You can sneak peek and
comment here:
https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004

- No bootstrap mode is a must-to-have for advanced users or users trying to
debug their connection. We should include this ticket in the scope.
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345

- I don't think it should be a priority for us to provide a GUI for Tor
Launcher. With a good developer experience for embedding Tor in
applications, apps can have the freedom to implement tor in the way they
consider it convenient for the use case. Perhaps Tails as an OS wants to
have a Network Settings panel, but Ricochet or Cwtch as messaging apps want
to hide the user's connecting flow and provide safe defaults.

- That said, I'd love to collaborate with Tails on guiding apps on
connecting to Tor in a way that is usable and respectful for end-users.

- Starting Tor Browser just for the launcher is an over-engineering IMO. I
agree with Richard that the need for a lite way (call it API or library) to
embed tor is a real need. It is a whole topic and is a latent need from the
entire ecosystem.

During the Demo days, we got the chance to see the multiple ways developers
are embedding tor in their applications, how diverse this ecosystem is and
how painful it is for devs to find a healthy way to do it. A useful
side-effect of this project could be planning a way to improve that
developer experience on implementing tor.

We have the chance to look beyond Tor Browser and think where Tor can be
embedded by listening to the community and providing cool state of the art
tools for implementing tor in their apps.

Again, thank you for your feedback! I'll go back to this thread once we
have an alpha release so you can test it early.

A

On Thu, Nov 5, 2020 at 7:00 AM anonym <anonym at riseup.net> wrote:

> Matthew Finkel:
> > On Wed, Oct 28, 2020 at 04:54:56PM +0100, anonym wrote:
> >> Matthew Finkel:
> >>> On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
> >>>> 2. Find, or write for scratch, another UI to configure & start
> >>>>      little-t-tor.
> >>>
> >>> Yes, and I think the Tor Project and the Tor community should keep this
> >>> in mind. As Richard said, a configuration flow like this is needed for
> >>> many different applications and we should think about providing drop-in
> >>> solutions for this (instead of everyone developing their own).
> >>
> >> Allow me to brainstorm a bit to see if we can avoid this extra
> implementation: what if Tor Browser can be told (perhaps with a
> --configure-tor-only parameter) to become essentially what Tor Launcher is
> now?
> >>
> >> In other words, it lock itself down by disabling most of Firefox UI
> (menu, url and tab bar, etc) and functionality (in particular, no
> browsing!), and only display the Tor bridge configuration bits. If we had
> this, 3rd parties like Tails, Ricochet etc could just depend on Tor Browser
> to act as a "Tor Launcher", and no extra implementation is needed.
> >
> >
> > I think we should have a different solution than "include a full web
> > browser for configuring Tor". This may be a short- or medium-term
> > solution, but there isn't a good reason for ricochet bundling Tor
> > Browser only for configuring Tor.
>
> Fair enough! To have something for the "short- or medium-term", while we
> are developing/waiting for the proper solution would be very relieving. My
> hope is that my proposal would be cheap to leave room for in your
> design/implementation, otherwise I don't think it is worth it and we should
> aim for the long-term solution directly, whatever that is.
>
> >> You also talk about censorship detection: it is a bit unclear if Tor
> Browser will try to detect it itself with some background work, or it this
> detection is reactive, e.g. by looking at what sites the users tries to
> visit; if it's the former, that would also fit with my proposal. If it's
> the latter, well that sucks, but at least 3rd parties would get something
> with the same power as the current Tor Launcher.
> >
> >
> > In the beginning this will likely be a hard-coded list of known regions
> > where censorship is implemented based on prior knowledge (such as OONI
> > reports). In the next iteration of this feature, we will likely try
> > detecting censorship via automatic probing. We don't know exactly how
> > we'll do this at this time.
>
> Ok! This first iteration sounds like it would work in my proposal too,
> great!
>
> >> How crazy does this sound?
> >
> > Slightly crazy :) but not too crazy
>
> Oh, yeah! :) So what is the proper way for me to formally suggest to add
> my proposal to the larger Tor Browser Quickstart project? Sending a merge
> request against tor-browser-spec.git:proposals/ideas/xxx-quickstart.txt?
>
> Cheers!
> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
>


-- 
Antonela Debiasi
UX Team Lead
torproject.org

@antonela
E2330A6D1EB5A0C8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20201130/89b6d5c9/attachment.htm>