[tor-dev] The future of Tor client software?

[Steven Engler <opara@xxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev