Hello everyone!
As indicated in our bug tracker a while ago[1] we have some strong
incentives to redo our ContactInfo field. I've collected all the
different use cases and combined them in a single proposal, discussing
some potential concerns and future work we could get built upon it. The
work is tracked on Gitlab as well[2] feel free to provide feedback there
or here on the list as a follow-up to this announcement. For your
convenience the proposal text is included below (if you like reading the
.md file on Gitlab, see my personal repository for the latest draft[3]).
"""
```
Filename: 100-contactinfo-mandatory-email-address.md
Title: Restricting ContactInfo to Mandatory Email Address
Author: Georg Koppen
Created: 2023-10-21
Status: Open
```
## Overview
This document proposes to change the ContactInfo field from a free text
field to one that is only allowing an email address. Additionally,
providing such an email address will be required after this proposal is
implemented. This is a normative document.
## Motivation
Being able to reach out to and contact relay operators (bridge operators
are included in that group) is important for our day-to-day work at Tor.
While this has been brought up in the past as helpful in our fight
against malicious relays, it goes well beyond that use case and is
affecting general network health work, community-building efforts and
quickly deploying anti-censorship related security fixes among other
things.
Tor is providing a `torrc` configuration option, `ContactInfo`, which is
supposed to contain an email address (potentially obfuscated) under
which the relay operator may be reached. However, in practise this does
not work very well for two reasons:
1. `ContactInfo` is a free-form field which allows the operator to
include not just email addresses but essentially any kind of text
they want. This results in a lot of overhead when trying to contact
all operators and failures to do so because not everything added to
`ContactInfo` is a way to actually contact operators or undoing
`ContactInfo` obfuscation turns out to be too hard.
2. `ContactInfo` can be empty as it is not required for all operators
and in cases where it is supposed to be required (e.g. for operators
running more than one relay) the requirement is not enforced.
Over the years different teams at Tor developed different workarounds to
the issues mentioned above without addressing them directly. The goal of
this proposal is to make those workarounds obsolete.
## Fixing ContactInfo
As briefly mentioned in the [Overview section](#overview) the idea of
this proposal is deceptively simple: `ContactInfo` will be turned into a
field allowing just an email address, under which the operator can be
reached. Moreover, providing such an address will be a requirement for
all operators regardless whether they run one relay or many of them, or
bridges.
Why will we require an email address and not, say, a domain set up
somewhere or an account on our forum instead? Firstly, a lot of those
other potential options require a valid email address themselves in the
first place and would therefore just raise the costs for relay
operators. Secondly, email still scales way better than other
alternatives allowing us to reach more people in less time. And,
thirdly, email addresses are required anyway in other network related
infrastructure parts, e.g. the RIPE database for IP address space
allocation comes to mind or abuse contacts for dealing with potentially
malicious Tor traffic/Tor users.
Even though this proposal will not lay out the envisioned changes at a
technical level (for that to happen we'll need a corresponding
[tor-spec] proposal later on) there are a number of details to consider
mainly stemming from the status quo existing for years and the
accumulated usage patterns of the `ContactInfo` field "in the wild".
The remainder of this proposal will be devoted to explain those details
and address potential concerns related to them.
## Implementation
The C-Tor codebase is in maintenance mode and not accepting any new
features anymore (with a very narrow set of exceptions). We therefore
plan to have this change included solely in the upcoming Arti relay
work. Note: while we'll be using `ContactInfo` throughout this proposal
it does no mean that the respective configuration option for Arti relay
will be the same. It could just be [`contact`] or something else. The
important point is that this proposal applies to whatever is providing
the argument for the "contact" keyword in the server descriptor then.
Requiring a syntactically correct email address in an Arti relay
configuration option is necessary but not sufficient for our purposes.
Otherwise `ContactInfo` values like `nob...@example.com`, which is used
by some relays and bridges in the Tor network at the time of writing
this proposal, would be acceptable. However, in that case there would
be no way to get into contact with respective
