Matthew Finkel:
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).
Richard Pospesel:
On 10/28/20 4:54 PM, anonym wrote:
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?
This is essentially what Tails currently does with tor-launcher. And seconding Matt, depending on shipping an entire copy of Firefox et al is a non-starter.
I suspect Tails, Tor Browser and Ricochet all have overlapping but not identical requirements.
Exactly. I think that it might not be a realistic goal to provide a "drop-in solution" for all Tor applications. For example, different tools use different GUI kit: Tails uses Gtk and OnionShare uses Qt, etc.
It seems to me than a better approach might be to:
- Share GUI guidelines: describe screens and interactions for such a configuration tool after thorough usability tests. Tails is interested in working on this UX work together with Tor.
- Make it easier for such a GUI to get the information it needs from the Tor daemon. That's the part that Tor would have give technical support to, in collaboration with the affected projects.
This would also allow different tools from slightly diverging according to their needs instead of redesigning and rewriting something from scratch if the drop-in solution doesn't work for them.
But I know pretty much nothing about what is planned for the Tor Browser quickstart, both in the GUI and the backend, so maybe this doesn't make sense or would be over-engineering.