[tor-dev] blacklisting relays with end-to-end correlation capabilities?

[nusenu]

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161208/0c3b92d1/attachment.sig>