Disable discoverability to neighbours within Tribler overlay network

[teddyrogers]

Tribler 8.0.7, there is no option to disable torrents becoming visible/ discoverable to neighbours within Tribler overlay network. The current (cumbersome) method to prevent torrents becoming discoverable is to follow the method described here: #8326 (comment)

I propose a feature request to have an option in Tribler to disable/ enable torrents becoming visible/ discoverable to neighbours in the overlay network. The setting to be either global (for all torrents) and/ or (preferably) for each individual torrent. This makes it much easier than manually having to edit the configuration.json file.

This will help Tribler comply with and, not be banned, when used with private trackers/ torrents.

[absolutep]

would it not affect the ability to search torrents?
cause the closest 5 tribler neighbours are our database for search

[teddyrogers]

would it not affect the ability to search torrents? cause the closest 5 tribler neighbours are our database for search

Yes it would and that is the feature request, to have the option to remove a torrent from being discoverable using the search feature. There may be instances where you may not want a private torrent/ tracker being discoverable in the network.

[teddyrogers]

@qstokkink the more I think on the issue of searching for files within Tribler overlay network the more I question why it remains implemented in Tribler 8.x when the channels feature was removed.

If Tribler is intended for privacy enhanced file sharing in someway it contradicts why you would want to allow your neighbours to know what files you have available. In theory this could mean I am able to compile a list of files within the neighbourhood. I assume something similar is already going on with the "Popular" page?

The search queries being performed, I assume these are all sent to neighbours and if neighbours are performing a search I could monitor and collate all the search terms?

[qstokkink]

Most of our mechanisms only work when we have enough users. This goes for the decentralized torrent indexing, as well as anonymization.

If everyone keeps sharing the existence of torrents, it is impossible (or near impossible) to determine who added the torrent to our network and who is simply forwarding it. The same holds for Tor (or Tribler): if you are the only user of the service, it is easy to determine the one anonymizing path in the network and that some exit node data belongs to that user. By depending on the scale (i.e., number of users) of the/our network, it becomes near-impossible to link data to individual users (this is the idea behind "mixnets", if you want to read up on this). Ironically, the feature you're proposing kills the privacy in our client if everyone were to use it.

[teddyrogers]

@qstokkink thank you for the reply I have some further questions I hope you have time to respond to;

1. How does the search content feature currently function, is the intention search queries are sent to neighbours (in clear text?) to retrieve potential files listed in their Tribler sessions?
2. How is the "Popular" list compiled, for example, are file lists in Tribler session(s) sent to neighbours and vice-versa and those lists are aggregated by their respective Tribler clients and then on-forwarded to future Tribler neighbours?
3. Figuratively speaking, if there were a million Tribler users on the network and each had ten files how is this compiled and aggregated, would the Tribler network and/ or Tribler clients be able to scale up, transfer and sustain this amount of information?
4. If a network neighbour used a search query for "cars" and then a neighbours Tribler requested downloading of a torrent with "cars" in the title, can it be assumed that the search query originated from the neighbour requesting the search?

[qstokkink]

To answer your questions:

1. The queries are clear text formatted as an SQL query and answered by the databases of the random people you connect to: don't expect any encryption here.
2. These list are the aggregation of all swarm size checks forwarded by everyone. There is no direct relation with what anyone downloads. In fact, most of this information will be gathered and forwarded by people that did not download the particular torrent.
3. Given enough time, by random chance, everyone would know everything. However, we have a bias toward the most popular torrents. We have yet to see any overwhelming amount of information. If the database becomes to big for your liking, you can remove it.
4. See also my answer to (2): there is no way to tell that the person answering the query is actually downloading that content.

[teddyrogers]

@qstokkink thank you very much for the reply.

[absolutep]

I think this is very private torrent centric issue.

Private torrents from Private trackers generally force disable DHT from a torrent as they have strict criteria for seeding ratios.

Tribler being DHT centric will not bode well with private tracker torrents.

Tribler's DHT Focus: Tribler relies heavily on DHT for finding and sharing files. This means it connects users in a decentralized way, without needing a central authority.

Conflict with Private Trackers: Private trackers work differently; they rely on their own servers to manage and monitor downloads. Because Tribler uses DHT, which is open and decentralized, it doesn't fit well with the controlled environment of private trackers.

Developers should either bump it to 8.2 OR not implement it at all.

[qstokkink]

That is a good point. If we make this just a simple flag, we'll only get in trouble long-term. We'll need a special class of "private tracker torrents". I'll reschedule this for 8.2.0 then.