Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

As per discussion with David on bad-relays@ I'm opening this ticket as he requested.

We want to make it clear to tor relay operators that setting a proper ContactInfo (working email address) and MyFamily (fully mutual configuration) is strongly encouraged (required?) for relay operators that run more than 3 (?) tor instances, relays showing up without such configuration likely raise a red flag and might get rejected from the network.

places to update:

• manual page:

• ContactInfo

• MyFamily

• relay documentation (legacy/trac#24497 (moved))

changed milestone to %Tor: 0.3.3.x-final in legacy/trac

added 032-backport in Legacy / Trac component::core tor/tor in Legacy / Trac man in Legacy / Trac milestone::Tor: 0.3.3.x-final in Legacy / Trac network-health in Legacy / Trac owner::nickm in Legacy / Trac parent::24497 in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac review-group-28 in Legacy / Trac reviewer::catalyst in Legacy / Trac security-low in Legacy / Trac severity::critical in Legacy / Trac status::closed in Legacy / Trac tor-doc in Legacy / Trac type::enhancement in Legacy / Trac labels

Trac:
Parent: N/A to legacy/trac#24497 (moved)

Trac:
Keywords: N/A deleted, man, tor-doc added
Milestone: N/A to Tor: 0.3.3.x-final

Would it make sense to deprecate the ContactInfo field in torrc and replace it with a more structured format?

For example:

• ContactName the name that the relay operator would like to be identified as.
• ContactEmail the email address the relay operator would like to be contacted via.
• ContactComment (optional) an additional comment that will be rendered in the contact field in the descriptor.

We could then let Tor continue to use the contact field in the relay descriptor and render it using the three pre-defined fields:

"{{ContactName}} <{{ContactEmail}}>" if ContactComment is unset or empty. "{{ContactName}} <{{ContactEmail}}> ({{ContactComment}})" if ContactComment is set.

We could warn the operator if the relay has ORPort set, but ContactName and ContactEmail is missing.

I don't know if this has been discussed before elsewhere, but I have the feeling that people are using this field in some slightly unstructured manners.

A ContactInfo specification https://github.com/nusenu/ContactInfo-Information-Shareing-Specification tor-dev thread: https://lists.torproject.org/pipermail/tor-dev/2017-October/012507.html

Part 1: Make ContactInfo mandatory for operators running multiple relays / bridges:

based on the email from David (4 Dec 2017 18:07:08 -0500) on bad-relays I'm submitting a patch to make it clear to relay/bridge operators that a contact information is mandatory if you run more than one relay.

This should make bad-relays@ cases less problematic where we have a presumed relay group like [ 1 ] and have no way to contact the operator before removing these relays from the tor network (because historically such groups turned out to be malicious).

I didn't add to the man page what happens if you do not set it (your relays might get removed if we detect a very likely group of relays without contactInfo [ 1 ]), because that would make it longer.

This adds a single and clear statement to the ContactInfo entry.

tor.1.txt:

@@ -1716,7 +1716,8 @@
 [[ContactInfo]] **ContactInfo** __email_address__::
     Administrative contact information for this relay or bridge. This line
     can be used to contact you if your relay or bridge is misconfigured or
-    something else goes wrong. Note that we archive and publish all
+    something else goes wrong. ContactInfo must be set if you run more than
+    one relay or bridge. Note that we archive and publish all
     descriptors containing these lines and that Google indexes them, so
     spammers might also collect them. You may want to obscure the fact
     that it's an email address and/or generate a new address for this

[ 1 ] https://nusenu.github.io/OrNetRadar/2017/11/30/a6

As David suggested after the man page is updated (this should get backported), he plans to announce this change on the blog.

Trac:
Status: new to needs_review

I've incorporated that sentence, and noted the requirement in a few more places, in a new branch bug24526 in my public repository. I've put the warnings in separate paragraphs so that they stand out more. Still needs_review.

Thanks for making it even more clear and adding it to MyFamily as well!

MyFamily MUST be set if you run more than one relay or bridge.

Maybe we should make it clear that it is not enough to just set it but to also be a proper (mutual) MyFamily? I removed " or bridge." since the man page also says: "Do not list any bridge relay ..."

A proper (mutual) MyFamily MUST be set if you run more than one relay across multiple /16 networks.

the changes file says:

Document in more places...

That was not documented / was not a requirement before, right? So the changes file could say something like the following?

Documentation:

• Operators running multiple relays or bridges are required to set ContactInfo.
• Operators running multiple relays are required to set a proper (mutual) MyFamily.

I'm also no longer convinced we should make any distinction between single relay and group relay operator.

Trac:
Keywords: N/A deleted, review-group-28 added

There is a typo in the patch in src/config/torrc.sample.in - a stray 'n' at the beginning of a line.

Aside from that, seems fine, aside from the obvious issue that we are using a capital MUST to declare something that is a policy preference with no technical enforcement mechanism.

Ian Goldberg also mentioned them in https://lists.torproject.org/pipermail/tor-dev/2018-January/012762.html

Trac:
Status: needs_review to needs_revision

Trac:
Owner: N/A to nickm
Status: needs_revision to accepted

I've added a series of fixup commits to my bug24526 branch to try to fix the issues matched above. Shall I squash and commit?

Trac:
Status: accepted to needs_review

Looks good to me! Commit message typo: s/requied/required/

Trac:
Reviewer: N/A to catalyst
Status: needs_review to merge_ready

fixed and squashed and merging; thanks!

Trac:
Status: merge_ready to closed
Resolution: N/A to implemented

thanks for merging!

Will you backport this change?