Hi,
I've been working Ricochet, and we also will need something like this in the long term (for instance, adding support for the various pluggable-transports). Ideally I'd like to have a lightweight library (with C abi) which we can all use for launching/configuring/managing a tor process (without any dependency on a particular UI toolkit). We all (tor-browser, tails, ricochet, etc) potentially need to do the same things in our various backends, so it'd be great if we had a common codebase for doing so.
best, -Richard
On 10/24/20 9:31 AM, intrigeri wrote:
Hi,
Antonela Debiasi (2020-10-23):
We've been defining an improved user flow for starting Tor Browser and connecting to Tor, with particular attention in censored contexts. The aim is making Tor Browser proactive in detecting censorship and improve the bridge's acquisition by making it easier for users to use them.
Thanks for this detailed proposal! I could not check the details since GitLab is not responding at the moment, but what you wrote looks great to me :)
FTR, in the context of Tails, since we don't allow the browser to control the Tor daemon's configuration, currently we're running Tor Launcher separately from the browser, as a XUL application. Once Tor Launcher is gone, presumably we won't be able to use the new in-browser UI. So in order to adjust to this change, likely we will need to:
Disable the new UI that configures & starts little-t-tor
Currently we do this with the TOR_SKIP_LAUNCH=1 environment variable. It would be great if we were still able to toggle the whole thing off in 1 single place with the new implementation :)
Find, or write for scratch, another UI to configure & start little-t-tor.
I believe Whonix may be in a similar situation.
Does this make sense to you? Did I miss or misunderstand anything?
Cheers! _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev