boldsuck:
On Donnerstag, 20. Juni 2024 02:00:18 CEST tor@xxxxxxxxxxx wrote: However, this non-exit list should not be activated automatically or with one- click. There is no reason to block non-exit relays.
I agree, maybe this open letter is better aimed at the security vendors that include DAN's (non-exit) Tor relays list on a blocklist by default, or without warning about potential impact to other legitimate services (universities, libraries, shared hosting providers, hobbyist email, etc)
Ransomware links are usually opened from emails and Tor is not running on company computers. Users cannot install anything either. How are they supposed to reach the hidden services?
Once the malware runs it will phone home over Tor to the .onion, from a network perspective this will look like a TCP connection to an entry node. I can see many reasons to maintain a list on known entry nodes to prevent unauthorized applications or users from connection out of a network. Those lists should not be enabled by default to block.
We should perhaps consider at the relay meeting on Saturday whether several relay operators or the Tor Project could write to dan.me.uk. He shouldn't make it so easy to activate the non-exit list. For example, UniFi devices are often installed by inexperienced admins. They simply click on all the block lists without knowing what they are.
Maybe reaching out to UniFi would be better than to the DAN project.I agree discussion with the rest of the relay community and a strong consensus on how to approach the over-blocking problem would be nice.
Regards,
Attachment:
OpenPGP_0x45E5F8C1504CDA42.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays