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:
- 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.
-
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
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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
--
Antonela Debiasi
UX Team Lead
@antonela
E2330A6D1EB5A0C8