This blog post from a few years ago suggests that using BitTorrent services over Tor is a bad idea for multiple reasons. However, it also suggests some fixes to get over these problems.
Is using a
It doesn’t make you anonymous. Torrent protocol wasn’t designed with anonymity in mind and there are a million ways you’re going to leak your actual IP address.
Tor is a TCP only network.
While this doesn’t give you the anonymity you wanted, it will hurt the network for other users.
It is not true that every node is an exit node in I2P. The I2P protocol does not officially have exit nodes—all I2P communication terminates at some node within the I2P network, encrypted end-to-end. It is possible to run a local proxy server and make it accessible to other users as an I2P service, creating an “exit node” of sorts, but this is something that must be set up deliberately; it’s not the default or recommended configuration. Users would need to select a specific I2P proxy service (exit node) to forward non-I2P traffic through and configure their browser (or other network-based programs) to use it.
Maybe I am missing something but that just feels like you are arguing semantics.
Traffic exits the sub-WAN from basically any of the computers/nodes in it. So it might not be a Tor Exit Node ™ but it still has all the dangers of it.
First, let’s start with the basics. An exit node is a node which interfaces between the encrypted network (I2P or Tor) and the regular Internet. A user attempting to access a regular Internet site over I2P or Tor would route their traffic through the encrypted network to an exit node, which then sends the request over the Internet without the I2P/Tor encryption. Responses follow the reverse path back to the user. Nodes which only establish encrypted connections to other I2P or Tor nodes, including ones used for internal (onion) routing, are not exit nodes.
Both I2P and Tor support the creation of services hosted directly through the encrypted network. In Tor these are referred to as onion services and are accessed through *.onion hostnames. In I2P these internal services (*.i2p or *.b32) are the only kind of service the protocol directly supports—though you can configure a specific I2P service linked to a HTTP/HTTPS proxy to handle non-I2P URLs in the client configuration. There are only a few such proxy services as this is not how I2P is primarily intended to be used.
Tor, by contrast, has built-in support for exit nodes. Routing traffic anonymously from Tor users to the Internet is the original model for the Tor network; onion services were added later. There is no need to choose an exit node in Tor—the system maintains a list and picks one automatically. Becoming a Tor exit node is a simple matter of enabling an option in the settings, whereas in I2P you would need to manually configure a proxy server, inform others about it, and have them adjust their proxy configuration to use it.
If you set up an I2P node and do not go out of your way to expose a HTTP/HTTPS proxy as an I2P service then no traffic from the I2P network can be routed to non-I2P destinations via your node. This is equivalent to running a Tor internal, non-exit node, possibly hosting one or more onion services.
Fair enough. Then you have the exact same risks as far as torrenting (the point of this thread) are confirmed. But still increased risks as far as csam.
What “increased risks as far as csam”? You’re not hosting any yourself, encrypted or otherwise. You have no access to any data being routed through your node, as it’s encrypted end-to-end and your node is not one of the endpoints. If someone did use I2P or Tor to access CSAM and your node was randomly selected as one of the intermediate onion routers there is no reason for you to have any greater liability for it than any of the ISPs who are also carrying the same traffic without being able to inspect the contents. (Which would be equally true for CSAM shared over HTTPS—I2P & Tor grant anonymity but any standard password-protected web server with TLS would obscure the content itself from prying eyes.)
You are still possessing csam while being used as a node to transit it.
A compromised (or even honey pot) node can show all the people who were “just holding it for a friend”. And ignoring that ISPs have historically cooperated in investigations, they also have many more lawyers.
So regardless of your ethical/moral concerns over facilitating the transit of csam, you are opening yourself up to being caught in a semi-tech savvy investigation.
This is not how the law is applied to packet switching.
If it was store and forward then maybe just maybe law enforcement would care, but anybody smart enough to set up an I2P node to research it and who tried to track where packets from from would first see the packets originate from their own local node at 127.0.0.1, then in the I2P console they could see that packet came in via an active half-tunnel from their own end interfacing with the endpoint node of the other side’s half-tunnel, and they would know that node has no idea what it’s sending (just like their ISP)
You are assuming good faith on behalf of law enforcement
You are assuming any investigation would go beyond the equivalent of “Well, we see these twenty peers in the download queue. Look up to see if we can send a DMCA”
You are assuming “I was just trying to help people share material they don;t want law enforcement to know about. How was I supposed to know it was csam? I am the real victim here” will work, at all.
1: then they would go after literally anybody running a node
2: their client will not see peers on another IP. It will just see their own I2P node. Any I2P aware software will also not have any IP addresses as peers, only I2P specific internal addresses. They will not even be able to associate an incoming connection to any one node without understanding the I2P network statistics console.
3: by this argument all anonymization tools should be illegal, Signal too, etc, and nobody should help anybody maintain privacy. In the real world there’s plenty of reasons why anonymization tools are necessary. And there will be literally zero evidence tying you to a crime. Preexisting legal precedence says an IP address alone is not enough.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
It is not true that every node is an exit node in I2P. The I2P protocol does not officially have exit nodes—all I2P communication terminates at some node within the I2P network, encrypted end-to-end. It is possible to run a local proxy server and make it accessible to other users as an I2P service, creating an “exit node” of sorts, but this is something that must be set up deliberately; it’s not the default or recommended configuration. Users would need to select a specific I2P proxy service (exit node) to forward non-I2P traffic through and configure their browser (or other network-based programs) to use it.
Maybe I am missing something but that just feels like you are arguing semantics.
Traffic exits the sub-WAN from basically any of the computers/nodes in it. So it might not be a Tor Exit Node ™ but it still has all the dangers of it.
No, that’s not how I2P works.
First, let’s start with the basics. An exit node is a node which interfaces between the encrypted network (I2P or Tor) and the regular Internet. A user attempting to access a regular Internet site over I2P or Tor would route their traffic through the encrypted network to an exit node, which then sends the request over the Internet without the I2P/Tor encryption. Responses follow the reverse path back to the user. Nodes which only establish encrypted connections to other I2P or Tor nodes, including ones used for internal (onion) routing, are not exit nodes.
Both I2P and Tor support the creation of services hosted directly through the encrypted network. In Tor these are referred to as onion services and are accessed through *.onion hostnames. In I2P these internal services (*.i2p or *.b32) are the only kind of service the protocol directly supports—though you can configure a specific I2P service linked to a HTTP/HTTPS proxy to handle non-I2P URLs in the client configuration. There are only a few such proxy services as this is not how I2P is primarily intended to be used.
Tor, by contrast, has built-in support for exit nodes. Routing traffic anonymously from Tor users to the Internet is the original model for the Tor network; onion services were added later. There is no need to choose an exit node in Tor—the system maintains a list and picks one automatically. Becoming a Tor exit node is a simple matter of enabling an option in the settings, whereas in I2P you would need to manually configure a proxy server, inform others about it, and have them adjust their proxy configuration to use it.
If you set up an I2P node and do not go out of your way to expose a HTTP/HTTPS proxy as an I2P service then no traffic from the I2P network can be routed to non-I2P destinations via your node. This is equivalent to running a Tor internal, non-exit node, possibly hosting one or more onion services.
Fair enough. Then you have the exact same risks as far as torrenting (the point of this thread) are confirmed. But still increased risks as far as csam.
What “increased risks as far as csam”? You’re not hosting any yourself, encrypted or otherwise. You have no access to any data being routed through your node, as it’s encrypted end-to-end and your node is not one of the endpoints. If someone did use I2P or Tor to access CSAM and your node was randomly selected as one of the intermediate onion routers there is no reason for you to have any greater liability for it than any of the ISPs who are also carrying the same traffic without being able to inspect the contents. (Which would be equally true for CSAM shared over HTTPS—I2P & Tor grant anonymity but any standard password-protected web server with TLS would obscure the content itself from prying eyes.)
You are still possessing csam while being used as a node to transit it.
A compromised (or even honey pot) node can show all the people who were “just holding it for a friend”. And ignoring that ISPs have historically cooperated in investigations, they also have many more lawyers.
So regardless of your ethical/moral concerns over facilitating the transit of csam, you are opening yourself up to being caught in a semi-tech savvy investigation.
This is not how the law is applied to packet switching.
If it was store and forward then maybe just maybe law enforcement would care, but anybody smart enough to set up an I2P node to research it and who tried to track where packets from from would first see the packets originate from their own local node at 127.0.0.1, then in the I2P console they could see that packet came in via an active half-tunnel from their own end interfacing with the endpoint node of the other side’s half-tunnel, and they would know that node has no idea what it’s sending (just like their ISP)
1: then they would go after literally anybody running a node
2: their client will not see peers on another IP. It will just see their own I2P node. Any I2P aware software will also not have any IP addresses as peers, only I2P specific internal addresses. They will not even be able to associate an incoming connection to any one node without understanding the I2P network statistics console.
3: by this argument all anonymization tools should be illegal, Signal too, etc, and nobody should help anybody maintain privacy. In the real world there’s plenty of reasons why anonymization tools are necessary. And there will be literally zero evidence tying you to a crime. Preexisting legal precedence says an IP address alone is not enough.