Hi tor-dev,
In the past, there were generally two options for supporting Tor in an application.
1. Require the user to install the tor daemon (ex: apt install tor, Tor Expert Bundle, etc) and configure the application to use its SOCKS proxy.
2. Bundle the tor binary with the application (ex: Tor Browser) and have the application use the app-specific tor process as the SOCKS proxy.
I'm not clear on how this changes in an Arti world. Arti currently has a Rust Tor client library for applications, and a CLI application to run a SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd service) for clients like with the current tor package? In a future where Arti replaces the Tor client and relay code, or when Arti is recommended for all client-related use cases, will there continue to be a Tor daemon with client support?
I see various possibilities for developers who wish to use Tor in their applications:
1. Require users to install/run a Tor system service (whether it's tor or arti). - pros: - shared resource usage (mainly circuits) between applications - familiar to experienced Tor users - cons: - requires an additional installation step for users - easy to break by users (for example changing their SOCKS port) - can't modify the Tor client's configuration (ex: can't enable DNSPort, change SocksPort flags, etc)
2. Bundle tor/arti binaries with the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - cons: - can be brittle (ex: an application is already using port 9150) - resources/circuits are not shared between applications - more work for the application developer (needs to build and bundle the tor binary) - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date
3. Use the arti-client library in the application. - pros: - simple for users (no extra configuration needed) - more control over the Tor client's configuration - easy to use for rust application developers - cons: - likely difficult to use in non-rust applications (writing an ffi for the async arti-client API doesn't sound fun) - resources/circuits are not shared between applications - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date
4. Require users to install/run a Tor transparent proxy or TUN adapter. - pros: - should probably "just work" (ex: no SOCKS port that can change or need to be configured) - cons: - requires an additional installation step for users - can't modify the Tor client's configuration - users likely don't want to proxy all their traffic through Tor - slowdowns due to latency from DNS lookups (RELAY_RESOLVE instead of sending the hostname in the RELAY_BEGIN) - no stream isolation support (maybe?)
Are there any guidelines for what method should be used under different circumstances? For example using the arti-client library in an email client seems reasonable since a longer startup time while it builds circuits isn't a big deal. But it might be a bad idea to use the arti-client library in cURL, which would need to build circuits each time curl is invoked in a shell script.
- Steve