I do not think that this is worthwhile. It establishes a precedent where setting your contact info is something that gets you banned, potentially incorrectly because it's unauthenticated, whereas we're unable to identify people who actually maliciously run several relays without such indicators.
"actually maliciously" somehow implies that openly run groups (all relays have the same contact info) are certainly not malicious because they do not try to hide? (set contact info) While I even assume that this is true for most such operators, it does not have to be the operator itself as soon as his admin machine gets compromised.
Since openly run groups are not blacklisted there is no reason for someone with malicious intents to to even try to hide.
If we did this, also why would we blacklist the nonexit relays? That seems to not make sense, as a relay operator could have multiple relays that act as guard and exit simultaneously.
Exit relays with the guard flag have usually a guard probability of 0% according to onionoo. Since exit capacity is harder to get I was suggesting to blacklist the guard-only relays of such groups, so the exit capacity could still be used while breaking the end-to-end capabilities (if we can assume onionoo's guard_probability to be correct).
also see: https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html
On 08 Dec 2016, at 15:02, nusenu nusenu@openmailbox.org wrote:
If we did this, also why would we blacklist the nonexit relays? That seems to not make sense, as a relay operator could have multiple relays that act as guard and exit simultaneously.
Exit relays with the guard flag have usually a guard probability of 0% according to onionoo. Since exit capacity is harder to get I was suggesting to blacklist the guard-only relays of such groups, so the exit capacity could still be used while breaking the end-to-end capabilities (if we can assume onionoo's guard_probability to be correct).
This is not guaranteed by the design.
-
nusenu -
Sebastian Hahn