Anonymity despite of destination (identity) IDs of peers?

[RootWebNutrient]

In I2PSnark one can click on x / y peers to see their IDs and in postman one can even see IDs of users who seed or download any given torrent. There also is information about the download progress. The ID is the same across different torrents.

Isn't this a major security vulnerability / risk to anonymity?
Shouldn't this functionality to see this info be removed in I2P somehow?

If it's the same download percentage, it's the same user. A combination of torrents can also be used to identify a user. People may even scrape postman to get these IDs which may be the biggest problem here and why I wonder why that site or I2P has this enabled. One could compile a list of things a user has downloaded. This means if the user is compromised during any session for whatever reason then all the torrenting activity may be known. One could maybe also use the list of things downloaded/seeding to do traffic analysis or similar things to identify the user. I wonder if this ID could also be used by admins of eepsites or people with access to their logs. I may be wrong but I think this is a big risk to anonymity.

This may be worth a second thread but it's also relevant here: is there a way to enable seeding of all finished downloads but to not to actually seed until somebody actually wants to download something? This may mitigate the above problem to some extent as one would only appear as seeder of a few things where a seeder is needed which would prevent torrents from getting abandoned.

[lgillis]

Hi RootWebNutrient!

This is how I2P works. The software replaces your Internet address with local I2P addresses, which they call “destinations”.

Whether you write here in the forum or with your trusted BitTorrent provider, whether you use the internal IRC or view or operate a website, these destinations are used everywhere to identify you as the origin of the data.

Now it is usually the case that only you know the destinations you use. Your secret is kept by routing your destinations through so-called tunnels, which serve to conceal their origin. (Of course, there is also encryption, heavy math and a pinch of fairy dust, but we want to keep things simple at this point.)

Another security aspect is the subdivision or separation of your activities (see above) by assigning separate destinations. In other words, your BitTorrent destination is fundamentally different from your HTTP destination.

So it is in the nature of things that everyone involved will see your destination. Of course, if you are using BitTorrent to distribute your torrent, all participating trackers will know your destination. If you use a closed tracker to distribute your torrents that requires you to register, that tracker will also know your HTTP destination.

is there a way to enable seeding of all finished downloads but to not to actually seed until somebody actually wants to download something?

The procedure is called scratching or something similar, I2PSnark should also be able to do this.

(And as always, if I'm wrong here or there are problems with the translation into English, please don't hesitate to point them out.)

[anikey]

You need an address (i.e. an identity) to send and receive data across a network (so that you can be addressed). In I2P, Destinations are such identities.

If you want to separate your torrents, you might want to try running multiple torrent clients (connected to one i2p router) - each of them would create its own destination. And what I2P does is it ensures that Destinations are not linkable to each other nor to the Routers they are hosted on (to the extent permitted by tunnel lengths and statistics and stuff like that).

If you put multiple torrents on a single client (a single Destination), external observers may trivially learn that these torrents are seeded on the same client. So, if you don't want torrents linked, host them on different torrent clients (but on the same I2P Router) - it will be indistinguishable from multiple people seeding different torrents.

But the catch is that you are not advised to create too many Destinations, as they collectively will create lots of tunnels, which will strain the network and (maybe, maybe) make your router stand out more. Therefore, you are advised to categorize your torrents according to your wish of them being "linked" with each other, preferably the less categories the better.

You should notice that I've been saying "same I2P router" - you are advised to run only one i2p router per computer - because if you run multiple routers:
- it will make your IP stand out, and more suspicious (others may think it's a Sybil attack and maybe even block it)
- it will strain the network (each router also maintains exploratory tunnels, so the more routers, the more tunnels)
- it is less efficient (ram and cpu)

I would also like to add to lgillis's post that you may create different HTTP destinations as well (there is nothing fundamental about them that requires it to be only one, or anything like that). And you would switch between them by switching proxy ports in your browser (or using different browser profiles with one proxy per profile).

[RootWebNutrient]

Thanks for your explanations. To recap: people see a unique destination for your across torrents but it's not your id but the id of the intermediary node that's in your direction. The identifier is different for HTTP so it's not the same as the one used for torrenting which can reduce the risk to anonymity but would still be linkable if you log in to a tracker where you added some torrent files as it could match the HTTP destination with the destination of the seeder (or first seeder) of the added torrents. One could also download torrents one at a time (or one at a time per client) and until it has fully finished to minimize this risk which probably is not feasible for most users and does not fully solve the problem anyway.

You didn't really explain how my concerns about the risk anonymity would be averted. For example that users across torrents can be detected by the time the peer starts downloading these and the download percentage so it is not indistinguishable even when using a separate client for just one torrent each which is something users don't do anyway.
This may currently be the largest risk to anonymity in I2P or security vulnerability. I suggest this is worked on next year. I think maybe one could solve this problem by:

• having a unique destination for every running torrent and

• hide the exact progress percentage from other users (if a peer is at 24.34% where the former destination left off that is the same user) and

• make it impossible for tracker sites like postman to show destination IDs and progress percentage for even users not running that torrent so that these can only see things like whether or not there is a 100% seeder or how many seeders and leechers there are

• [ maybe there are more options ]

In addition, enabling seeding of all finished downloads but to not to actually seed until somebody actually wants to download something in I2PSnark also seems needed or at least very useful. It doesn't seem to be called "scratching" and I could not find any setting for that in the I2PSnark configurations which only has a setting to autostart all torrents. To be clear enabling this would start a torrent and make one's destination id only visible if a peer is trying to download a torrent but not finding a peer (or no 100% seeder or no fast one). This would minimize exposure of one's destination id and make sure torrents stay alive. This could work for example if there was some kind of announcement process when a user tries to download a torrent but does not find a seeding peer for a while, sending out some signal like looking for seeders which is received by all those users who have that torrent in their I2PSnark torrents list.

[lgillis]

An unbiased view of what is happening from the outside can be very interesting. I am firmly convinced that our software developers will take up any innovative ideas that will contribute to an improvement.

Let me make a quick suggestion. With your obviously high demand for security, I think it would make sense to consider an OpenTracker instead of subjecting yourself to the regime of a private provider. Trackers like Postman do not belong to the democratic community, as is often assumed, and are not part of the I2-Project, but are privately owned. And this can sometimes lead to conflicts of interest, as the Corona years have shown the attentive participant. An OpenTracker also eliminates many of the problems you mentioned above. You could also use a BitTorrent client, that provides you with more control.

[anikey]

To recap: people see a unique destination for your across torrents but it's not your id but the id of the intermediary node that's in your direction.

Kind of, but that's not the important thing.

I2P obscures IP addresses, but the "in-net peers" (in-network servers AND clients, such as http, irc, bittorrent, etc.) still have to be addressed somehow, so I2P assigns "Destinations" to them. Destinations are basically cryptographic key pairs. You can generate lots of them.

I2P obscures IP addresses, so it must route traffic through other routers. To do that, it builds inbound (IB) and outbound (OB) tunnels. These tunnels are basically agreements between your router and 1-8 other routers, that they forward the traffic sent through the tunnel, until the tunnel expires (the expire time is 10 minutes). Think of these arrangements as "chains" that your packets go through. (Note: there are usually multiple tunnels built, for load balancing and redundancy).

Tunnels are unidirectional (traffic can only be sent one way; this is why there is a distinction between IB and OB tunnels). The router at the "sending" end of the tunnel (the first router) is called a "gateway" (GW), and the last router is called the "endpoint" (EP).

In your own tunnels, you are the "outbound gateway" and the "inbound endpoint". The other ends of the tunnels are, respectively, the "outbound endpoint" (OBEP) and the "inbound gateway" (IBGW).

Now, destinations on their own are just a bunch of numbers not tied to reality. What ties them to reality is "LeaseSets". LeaseSets list some IBGWs that allow you to reach a specific destination. LeaseSets are published to the distributed NetDB, but the post is getting so long i won't explain it right now.

OBEPs are what sends your traffic to the other end's IBGWs.

What people (i2p sites) theoretically might be able to see see when you connect:
1) IBGWs of the current Destination
2) OBEPs of the current Destination
3) the current Destination's public key

What people practically can see when you connect: 1), 3).
(info about OBEPs is unnecessary to the other end, so it may as well not be tracked anywhere).

What people actually look at: 3) only the Destination public key.
(IBGWs, like tunnels, are ephemeral and usually bear no significance).

You can create multiple destinations on the same router, and they will not be linkable to each other, much like destinations are not linkable to the IP addresses they are hosted on. This allows you to be less trackable, and also allows you to truly have multiple identities inside I2P.

Please note that the "unique destination" (the public key) is not "the id of the intermediary node" (OBGW/IBEP).

The identifier is different for HTTP so it's not the same as the one used for torrenting which can reduce the risk to anonymity but would still be linkable if you log in to a tracker where you added some torrent files as it could match the HTTP destination with the destination of the seeder (or first seeder) of the added torrents. One could also download torrents one at a time (or one at a time per client) and until it has fully finished to minimize this risk which probably is not feasible for most users and does not fully solve the problem anyway.

Inherently, at the network layer, there are no distinctions between "HTTP tunnels" or "bittorrent destination" or whatever. These are just conveniences from layers closer to the user. Usually, when using I2P with bittorrent enabled, the destinations include:
- the http proxy destination (the one that can be accessed by setting browser proxy to localhost:<some port>).
- the bittorrent destination (which is used by all traffic from the bittorrent client, including HTTP tracker requests for peers and other bittorrent thingies).

Please note that it cannot just "match" the http proxy destination with the bittorrent destination. Because they will be completely different.

You didn't really explain how my concerns about the risk anonymity would be averted. For example that users across torrents can be detected by the time the peer starts downloading these and the download percentage so it is not indistinguishable even when using a separate client for just one torrent each which is something users don't do anyway.

As far as I know, hiding the percentage is not possible in Bittorrent, because Bittorrent needs to know what parts of the file(s) other peers have.
Partly because bittorrent clients tend to download the rarest pieces first, so that if the only clients hosting these pieces go down, they don't get lost.

I think maybe one could solve this problem by:

• having a unique destination for every running torrent and

For people with thousands of torrents in their clients, I'm sure the network would NOT be happy about that.

Firstly, building thousands of tunnels would overload the whole network.
Secondly, creating thousands of LeaseSets would overload the NetDB (some percentage of the whole network).

I've seen somewhere on i2p-projekt.i2p that the i2p maintainers do not recommend application developers to create more than (just) one destination per the whole application, unless the dev can talk about it with the i2p maintainers. (But i can't quite find where this is written).

• make it impossible for tracker sites like postman to show destination IDs and progress percentage for even users not running that torrent so that these can only see things like whether or not there is a 100% seeder or how many seeders and leechers there are

How Bittorrent works (nah just kidding, im not gonna explain two different big systems in one post)

(hereinafter Bittorrent is referred to as BT)

In order to download a torrent, a BT client needs to know the peers' addresses. In regular Internet, that would be IP addresses; in I2P, that is their Destinations.

A BT client usually finds torrent peers from a tracker (these are other sources like DHT [but that is just a distributed tracker], PEX [just exchanging peer addresses between each other, as an optimization to lighten the load on the tracker]), and BT clients report their progress to trackers too.
The tracker knows the addresses of the peers and gives it to your BT client.

If you "hide" destinations, it would make it impossible to communicate, because there are no addresses then.

Regarding percentages, I've written above.

Also, there might not be any 100% seeders, but instead different incomplete peers that are sharing pieces that they each have, to combine them and maybe get the whole file.

Your suggestion is kinda like "hiding ip addresses in bittorrent clients" - it can only be made at the UI level, but would be useless.

In addition, enabling seeding of all finished downloads but to not to actually seed until somebody actually wants to download something in I2PSnark also seems needed or at least very useful. It doesn't seem to be called "scratching" and I could not find any setting for that in the I2PSnark configurations which only has a setting to autostart all torrents. To be clear enabling this would start a torrent and make one's destination id only visible if a peer is trying to download a torrent but not finding a peer (or no 100% seeder or no fast one). This would minimize exposure of one's destination id and make sure torrents stay alive. This could work for example if there was some kind of announcement process when a user tries to download a torrent but does not find a seeding peer for a while, sending out some signal like looking for seeders which is received by all those users who have that torrent in their I2PSnark torrents list.

Downloaders also announce themselves to the tracker, and "hidden" uploaders may connect to them that way.
In fact, this exact feature is used as a way to "punch" NATs on the regular internet (a client behind NAT can initiate a connection to a peer without NAT, but not vice versa).

I don't know how that would affect both anonymity and efficiency.

Let me make a quick suggestion. With your obviously high demand for security, I think it would make sense to consider an OpenTracker instead of subjecting yourself to the regime of a private provider. Trackers like Postman do not belong to the democratic community, as is often assumed, and are not part of the I2-Project, but are privately owned. And this can sometimes lead to conflicts of interest, as the Corona years have shown the attentive participant. An OpenTracker also eliminates many of the problems you mentioned above. You could also use a BitTorrent client, that provides you with more control.

Yeah, but what OpenTrackers usually don't have is user-created torrent catalogs, sorted by categories, with descriptions, comments, and ratings.
Someone could make some sort of federated wiki though.