Skip to content

Document usecases for Arti

I think it's important to consider usecases for Arti (from the perspective of both users and integrators), so that we can figure out how to best meet the needs of those usecases.

I started thinking about this because of #1643 (closed) — figuring out what the ideal config file layout / format is seems like it depends significantly on what usecases we're imagining, which isn't something that is well-defined right now, as far as I can tell.

As examples, here are some usecases that I can imagine, in the long-term:

  • Tor relay
  • Tor relay (directory authority)
  • Onion service host (simple HTTP website)
  • Tor Browser
  • Orbot / Tor VPN / etc
  • Tails / Whonix / etc
  • Briar / Cwtch / Ricochet Refresh / etc
  • IRC
  • SSH
  • Email (IMAP / POP / JMAP / etc)
  • cryptocurrency wallets / Bisq / etc
  • cryptocurrency consensus or mining node

Many of these have a lot of complexity in them (for instance, is the user on mobile or on a desktop? what platform are they on? is their goal anonymity, censorship circumvention, or both?)

I think it would be good to consolidate these into something like "user stories" and put these in our docs. They can start out fairly sketchy, and as we actually start talking with users we can figure out more of the details. It's just good to have an idea of the whole landscape at the start.

Laying my cards on the table, the reason I care about this is because we're currently providing basically two artifacts: a arti binary that acts as a SOCKS proxy, and a set of Rust crates. I think that a SOCKS proxy is a very dangerous thing to give people, since a huge number of protocols have various kinds of information leaks that will break anonymity unless the user is very careful. I want us to carefully consider our usecases, so that we can make sure that users are using tools that are tailored to those usecases, and don't have any easy ways to be misused. My hope is that we can direct users as much as possible towards tools that embed Tor/Arti, either in the application or via configuration provided by projects like Tails or Whonix, and that we can keep the SOCKS server as something that is largely a debugging/development/integration tool, that we can warn end-users away from.

In any case, starting by documenting "what do users want to do?" is a good way to make sure that we make good decisions about how we expose users to the code that we're writing.