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
