Write "expectations for relay operators" document
Motivated by tpo/web/community#165, we could really use a document for relay operators which sets our expectations for what it means to run a relay properly.
This document would be the mirror image of #11 (closed), which as I understand it would be the guidelines for the bad-relays team on when a relay should no longer be permitted in the network.
The goal is to make it clear what we expect of relay operators, rather than leaving it implicit.
And with that preface, here is my first draft of five sections of a relay expectations document:
- Keep users safe:
- Don't look at, or modify, network traffic.
- Don't reveal user or destination IP addresses, or the timing or volume of connections.
- By default (e.g. unless you are debugging a specific thing), log at loglevel "notice", and leave SafeLogging on.
- If you run more than one relay, set the MyFamily option for each of them, to instruct clients to avoid using more than one in a circuit, and to help the network health team know which relays are really yours.
- Don't modify your Tor process to examine internal state. In particular, don't record v2 onion addresses.
- If you want to measure or study the Tor network, do it safely: write up your plan first and get feedback from the Tor Research Safety Board: https://research.torproject.org/safetyboard/
- Maintain good system op-sec:
- Run a version of Tor that is supported. You can see supported versions on this table: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases
- Watch your Tor logs for warnings and try to address them.
- Make sure to keep the rest of your system software up to date too.
- Try not to let the cops get your relay keys, but if they do, make sure we learn about it so we can block those keys from the network.
- Make sure your relay isn't broken:
- Tor relays need 10000+ file descriptors, so be sure your Tor package or startup script is raising your ulimit -n.
- Don't firewall outgoing connections. Tor relays need to be able to reach all other Tor relays, including new ones that are self-testing their reachability.
- Exit relays need a working DNS resolver. Also, don't use a DNS resolver that censors its answers.
- If there's a port or address block that your exit relay can't reach, be sure to reject it in your ExitPolicy, so clients can know to use a different exit.
- Sustainability:
- Don't try to run an exit relay at a place where you plan to just discard it and move on if the ISP complains to you. Running an exit relay involves advocacy to your ISP, to help them understand how Tor works and why it's important.
- If somebody tries to get you to backdoor or tap your relay, don't do it. Find a lawyer and fight it, and if you can't fight it, shut the relay down instead.
- Be a part of our community:
- Remember that running a relay is an act of transparency (even though being a Tor user is an act of privacy), because the way to strengthen trust in relays is by having a stronger community.
- Make an effort to meet other relay operators and developers in your area and at conferences and meetups.
- Be sure to set your ContactInfo to a working address in case we need to reach you.
- Running a relay is great because it helps to make Tor users safer. Please make sure you're not undermining Tor or Tor user safety in your other activities. For example, if your other hobby is developing DPI tools for Palantir, or making people fear or hate privacy tools, please do not also run a Tor relay.
- Read our social contract and the other community documents: https://gitweb.torproject.org/community/policies.git/tree/ If there is a question about whether you or your relay are following the expectations laid out here, these are the documents we will be using to guide our choices.