3 ms·

My apologies. I don’t believe that was their intent to create a network for csam. But after decades of it being used extensively for csam, why would they take n

My apologies. I don’t believe that was their intent to create a network for csam. But after decades of it being used extensively for csam, why would they take no corrective action?

ranger_danger 1y ago
Maybe because there isn't a known solution? CSAM is still distributed on the clearnet too... why isn't there a "solution" for that too? So far the only solutions people seem to have come up with is mass surveillance, and that's not an option.
- bnl_umass 1y ago
  There is a known solution. Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok. However, if a relay refuses to service an onion site directory look up, it will be banned by the Directory Authority. They could allow this today. But they don’t. That’s the simple solution. No surveillance. Not back door. No less privacy for everyone else. edit: This is easy to confirm. I’m not asking anyone to trust me.
  - ranger_danger 1y ago
    Exit nodes are not used for onion services. From https://onionservices.torproject.org/technology/properties/ https://onionservices.torproject.org/technology/properties/: > For the Tor network, Onion Services can alleviate the load on exit nodes, since it's connections don't need to reach the exits. Also: > Directory Authority. "These authorities are operated by trusted organizations or individuals with a strong commitment to the principles of privacy, security, and network neutrality." Emphasis on neutrality... it's not the job of network operators to police the sites people can and can't access, this is exactly why many people use Tor in the first place. > They could allow this today. But they don’t. Speaking for onion services... no, they cannot, because the entire design of the tor network prevents this in the first place. No relay in the circuit knows the final destination because it is encrypted multiple times (like an onion) and each hop can only see where it needs to go next, not what the destination is.
    - neutered_knot 1y ago
      I think the point is that exit node operators can filter traffic they don’t want to support. Guard and middle nodes are not given the same choice; they apparently must support all traffic or get booted. Why can’t other nodes have freedom to decide how they want to participate?
      - ranger_danger 1y ago
        > Why can’t other nodes have freedom to decide how they want to participate? Because the network was explicitly designed to not allow this... otherwise it becomes subject to censorship, which is one of the main goals they try to prevent. The (onion) address itself is never transmitted in plaintext through the Tor network... when you access an onion site, your Tor client encrypts the traffic multiple times, literally like an onion. No relay in the circuit knows the final destination.
        neutered_knot 1y 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.
        iamnothere 1y ago
        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.
  - basedrum 1y ago
    Your assumptions are based on faulty understanding of how tor works.
    - bnl_umass 1y ago
      I understand well how it works. I agree this is not possible today’s code base but that limitation is due to a design choice. It’s due to a policy decision that the privacy of children who have been sexually exploited is not as important as the privacy of others (including the privacy of people who sexually exploit children). It’s not a technical limitation. It’s a flaw. Specifically, it would be easy to add code to hsdir functionality to deny requests for onion sites that are known to be related to csam. Those sites could be announced by the DAs as part of the consensus file, for example. The Tor Project currently lets exit nodes filter by IP address as long as they announce that in their config; this new functionality is of the same kind in the abstract. This change would not be a backdoor. It’s not going to weaken the privacy of anyone using Tor. The current setup is an extremist position that children who have been abused are not deserving of privacy. It’s a position that all information deserves to be free even if that information is very clearly harmful to others and has no positive benefit to society. One can have that opinion but you won’t find many (outside of this thread) that agree.
  - torexitoperator 1y ago
    >Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok. That's simply not true. Exit operators who intentionally block websites are flagged as bad relays. https://community.torproject.org/policies/relays/expectations-for-relay-operators/#3-make-sure-your-relay-isnt-broken https://community.torproject.org/policies/relays/expectation... https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays#misconfigured-exit-relays https://gitlab.torproject.org/tpo/network-health/team/-/wiki...
    - neutered_knot 1y ago
      I think that is referring to the node exit policy, which explicitly allows particular ports and IP addresses to be blocked. https://support.torproject.org/relay-operators/exit-policies/ https://support.torproject.org/relay-operators/exit-policies... The documents you referred to just say you need to honor your own exit policy.

My apologies. I don’t believe that was their intent to create a network for csam. But after decades of it being used extensively for csam, why would they take no corrective action?

ranger_danger 1y ago

Maybe because there isn't a known solution? CSAM is still distributed on the clearnet too... why isn't there a "solution" for that too? So far the only solutions people seem to have come up with is mass surveillance, and that's not an option.

bnl_umass 1y ago
There is a known solution. Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok. However, if a relay refuses to service an onion site directory look up, it will be banned by the Directory Authority. They could allow this today. But they don’t. That’s the simple solution. No surveillance. Not back door. No less privacy for everyone else. edit: This is easy to confirm. I’m not asking anyone to trust me.
- ranger_danger 1y ago
  Exit nodes are not used for onion services. From https://onionservices.torproject.org/technology/properties/ https://onionservices.torproject.org/technology/properties/: > For the Tor network, Onion Services can alleviate the load on exit nodes, since it's connections don't need to reach the exits. Also: > Directory Authority. "These authorities are operated by trusted organizations or individuals with a strong commitment to the principles of privacy, security, and network neutrality." Emphasis on neutrality... it's not the job of network operators to police the sites people can and can't access, this is exactly why many people use Tor in the first place. > They could allow this today. But they don’t. Speaking for onion services... no, they cannot, because the entire design of the tor network prevents this in the first place. No relay in the circuit knows the final destination because it is encrypted multiple times (like an onion) and each hop can only see where it needs to go next, not what the destination is.
  - neutered_knot 1y ago
    I think the point is that exit node operators can filter traffic they don’t want to support. Guard and middle nodes are not given the same choice; they apparently must support all traffic or get booted. Why can’t other nodes have freedom to decide how they want to participate?
    - ranger_danger 1y ago
      > Why can’t other nodes have freedom to decide how they want to participate? Because the network was explicitly designed to not allow this... otherwise it becomes subject to censorship, which is one of the main goals they try to prevent. The (onion) address itself is never transmitted in plaintext through the Tor network... when you access an onion site, your Tor client encrypts the traffic multiple times, literally like an onion. No relay in the circuit knows the final destination.
      - neutered_knot 1y 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.
        iamnothere 1y ago
        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.
- basedrum 1y ago
  Your assumptions are based on faulty understanding of how tor works.
  - bnl_umass 1y ago
    I understand well how it works. I agree this is not possible today’s code base but that limitation is due to a design choice. It’s due to a policy decision that the privacy of children who have been sexually exploited is not as important as the privacy of others (including the privacy of people who sexually exploit children). It’s not a technical limitation. It’s a flaw. Specifically, it would be easy to add code to hsdir functionality to deny requests for onion sites that are known to be related to csam. Those sites could be announced by the DAs as part of the consensus file, for example. The Tor Project currently lets exit nodes filter by IP address as long as they announce that in their config; this new functionality is of the same kind in the abstract. This change would not be a backdoor. It’s not going to weaken the privacy of anyone using Tor. The current setup is an extremist position that children who have been abused are not deserving of privacy. It’s a position that all information deserves to be free even if that information is very clearly harmful to others and has no positive benefit to society. One can have that opinion but you won’t find many (outside of this thread) that agree.
- torexitoperator 1y ago
  >Did you know that the Tor Project allows exit nodes to filter based on the clear internet IP. So filtering is ok. That's simply not true. Exit operators who intentionally block websites are flagged as bad relays. https://community.torproject.org/policies/relays/expectations-for-relay-operators/#3-make-sure-your-relay-isnt-broken https://community.torproject.org/policies/relays/expectation... https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays#misconfigured-exit-relays https://gitlab.torproject.org/tpo/network-health/team/-/wiki...
  - neutered_knot 1y ago
    I think that is referring to the node exit policy, which explicitly allows particular ports and IP addresses to be blocked. https://support.torproject.org/relay-operators/exit-policies/ https://support.torproject.org/relay-operators/exit-policies... The documents you referred to just say you need to honor your own exit policy.