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@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:
- 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