Expectations-for-Relay-Operators.md

-Main ticket: [#18](https://gitlab.torproject.org/tpo/community/relays/-/issues/18)
+The Expectations for relays operators document strives to be a clear and comprehensive guide for the relay operator community.
+This is an effort to keep the Tor community and the network safe, healthy, and sustainable.
 
-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.
+Version 1.0\
+Last updated: 2022-04-18
 
-This document would be the mirror image of tpo/network-health/team#11, 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.
+### 1. Keep users safe
 
-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:
-
-1. 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.
+* Don't reveal user or destination IP addresses, or the timing or volume of connections. For instance, don't create a publicly available webpage showing bandwidth history or any statistics about the machine (e.g. CPU/RAM usage) as these can be used in surprising ways to attack users.
 * 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/
-
-2. 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
+* Running a bridge and a public relay using the same IP address is discouraged as censored users won't be able to connect to the network.
+* 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 onion addresses.
+* Don't proxy your relay exit traffic through a VPN or other proxies.
+It can introduce more surface area (more places get a chance to see the traffic). Second, it seems to be correlated with people trying to do shady things with their traffic, and third, having that extra hop can impact the network performance.
+* 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/).
+
+### 2. Maintain good system operational security (opsec)
+
+* Run a version of Tor that is supported.
+You can see supported versions on the [Network Team wiki page](https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases). Relays and bridges running Tor versions that are end-of-life (EOL), unsupported versions, or with known security vulnerabilities we will follow the [Relay EOL Policy](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-policy) and  remove from the network.
 * 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.
+* Try not to let adversaries get your relay secret keys, but if they do, make sure to contact the [bad relays team](community-resources/bad-relays/), so we can block those keys from the network.
 
-3. 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.
+### 3. 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.
 
-4. 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.
+### 4. 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.
+
+### 5. Be a part of our community
 
-5. 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.
+* Be sure to set your `ContactInfo` to a working email 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 surveillance tools for a shady company, or making people fear or hate privacy tools, please do not also run a Tor relay.
\ No newline at end of file
+* 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.
+
+### Contributing to this document
+
+If you have feedback for improving this document, you can open a new ticket on the [Community web repository](https://gitlab.torproject.org/tpo/web/community).
+The repository is also available on [Anon-Ticket](https://anonticket.onionize.space/), which does not require a GitLab account.
\ No newline at end of file