Sebastian Hahn wrote (2016-12-08):
On 08 Dec 2016, at 14:03, nusenu nusenu@openmailbox.org wrote:
Dear tor directory authorities,
TLDR: Would you blacklist relays with end-to-end correlation capabilities?
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.
Additionally, it's yet one more thing to update the dirauths' configs for, but with rather more overhead as we might get multiple mails back and forth about how MyFamily is annoying to maintain, how they're just trying to help, etc. All not so bad arguments.
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. I think we'd need to blacklist at least all the exit relays, if not all of them. BadExiting them would then be the more sensible choice. Scarcity of resources has in the past led us to bad designs like Valid/Invalid relays etc, which causes way more annoyances than good things.
I understand dir auth operators have limited resources, but if you (most of the dir auths) agree that blacklisting specific relays to protect tor end users makes sense:
Would you agree on handling a limited amount (6?) of such 'end-to-end' cases per year?
I.e. one case every 2 months if the operator has a guard probability
0.1% and exit_probability >0.1% and didn't fix the problem within a
month after getting contacted?
Note: Luckily the list of such known potential operators is currently very short (<5).
In the past month I had some positive effect when trying to contact relay operators [1], but unfortunately the biggest operators (by consensus weight) are not to motivated to fix their configuration in a reasonable time frame.
thanks, nusenu
[1] https://lists.torproject.org/pipermail/tor-relays/2016-December/011520.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011507.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011476.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011486.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011521.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011426.html