Hacker News new | ask | show | jobs
by neutered_knot 266 days ago
It is absolutely a design decision. I don’t understand though how allowing exit nodes to filter (by port and IP) doesn’t permit censorship but allowing internal nodes to not complete connections to onion sites does. I do understand that early nodes on the path are unaware of what the traffic but it seems pretty straightforward to allow nodes to not become rendezvous points for onion sites.
1 comments

You are welcome to fork Tor and create a version that uses this approach, but good luck getting people to use it.

Conversely, even if the official project implemented an onion blacklist, a fork would quickly appear to remove it. And node operators would likely prefer that one.

Anyone with any sense understands that introducing a node blacklist creates the capability to expand the use of that blacklist in the interest of political and/or military censorship. The Tor project, Tor devs, and node operators are adamantly opposed to any such censorship capabilities. Therefore it will not happen, period.

That’s not at all what I proposed. Not even close.

Edit: on second look I can see how you could think it was. I’m just proposing that if you run a node you be allowed to not become a rendezvous point for onion sites.

Ah, I misunderstood. In any case, onion traffic is not flagged as such, so nobody but the last hop would even know that onion traffic is being passed. Allowing the last node to kill the whole circuit seems like it would cause routing problems and/or contribute towards deanonymization, as would flagging onion traffic at every step of the journey.