"Making Bittorrent anonymous and impossible to shut down"

[teddyrogers]

The Tribler description mentions, "the only way to take Tribler down is to take The Internet down". Tribler only uses three to four exit nodes in the range of, "<<removed>>". I assume these IP's are part of a server network that provides and manages official TOR services, exit nodes and relays.

If this server went down and/ or IP's became blocked/ blacklisted how is Tribler 8.x designed to behave and cope with this?

"<<removed>>", is only used in Tribler 7.x?

[qstokkink]

Tribler does not have any hardcoded exit nodes. Whenever someone starts an exit node, we find them using a decentralized overlay network. If these nodes are unreachable or go offline, other nodes are simply found used instead. So, as a Tribler user, you will only notice momentary bump in download speed as Tribler switches to different exit nodes.

Only if governments work together in an international effort to take down all exit nodes in all jurisdictions, or ISPs start blocking Tribler traffic, just because it is Tribler traffic and without any cause, then Tribler will stop working. That is the story behind our marketing one-liner.

I will note that exit nodes are run by people who both volunteer their bandwidth and run the risk of legal retribution for your anonymous downloads. So, paying them back by plastering their IP here on GitHub is something I would consider to be quite rude, to say the least: I'll remove the IPs from your post.

[teddyrogers]

We can see that in the order of ~50 exit nodes exist (depending on who is online, and when - this is an estimate)

@qstokkink my experience does not correlate anywhere near the numbers you are stating and they all appear to be exiting through one server/ data centre.

If anyone manages to take down all exit nodes, nobody will be able to download anonymously anymore

This part of the statement, "impossible to shut down", is not exactly true. The weakness of Tribler is the (lack of) exit nodes and inability/ availability to create additional exit nodes at will. I assume this weakness is inclusive of being able to create and establish Triblers bootstrappers.

Why am I querying this? I am comparing how resistant the Tribler network is of being shutdown against I2P, and (whilst be frowned upon) the possibility of users using the TOR network.

[qstokkink]

I'm repeating myself a little bit here, but you don't seem to be connecting all the available exit nodes. Also, quoting myself, "Anyone can still just choose to run one, if they are so inclined.", so your comment "inability/ availability to create additional exit nodes at will" is not the case.

Lastly, to help with your comparison: with the exception of (partially) ad hoc networks, all decentralized technology over the Internet has the same fragility. Be it Tribler, Tor, I2P, or even Bitcoin: take away the introduction servers (a.k.a. "rendezvous nodes" or "bootstrap servers") and the network doesn't do anything anymore¹. You'll just be sitting there, all alone and unconnected. Of course, I2P doesn't even attempt to exit data and something that doesn't exist cannot be taken down 🙂. Tribler also has an e2e-encrypted mode like I2P, but it additionally allows data to exit the network through exit nodes (so - worst case - Tribler equals I2P).

Footnotes

1. As an aside, you don't necessarily need to physically take down the servers. Most notably, with an "eclipse attack" you can simply drown out all useful connections. ↩

[teddyrogers]

you don't seem to be connecting all the available exit nodes

@qstokkink How to confirm this is really what is happening, if it is a bug, and should it be an issue do you have any suggestions on how to resolve?

all decentralized technology over the Internet has the same fragility

Fully agree with you. Where I was leading to is that - I believe - Tribler could be made more resilient if some of the what has been mentioned here was adapted so that Tribler could be made to be truly independent. Triblers being able to setup, and to establish, their own Tribler bootstraps and create exit nodes - from within Tribler itself. If for some mysterious reason the default Tribler bootstraps go offline (a group) or individual/s could create their own or join others. Should there be no exit nodes the possibility remains, within Tribler, to easily create them. I am aware, "that the exit node script is not exactly hidden", though its not exactly common knowledge or widely known either (because dangers lurk within). For Triblers future roadmap, instead of focusing on anonymity and encryption, maybe some ideas could be considered for independence and resilience.

[qstokkink]

How to confirm this is really what is happening, if it is a bug, and should it be an issue do you have any suggestions on how to resolve?

By design, you can't really know. This is why we run tests and experiments, and we run network crawls, to make sure that everything is still (at least seemingly) running as it should.

Triblers being able to setup, and to establish, their own Tribler bootstraps and create exit nodes - from within Tribler itself.

Let me start by saying that you can run this script and have your bootstrap node up-and-running (of course, your firewall needs to allow connections). Any Tribler user that wants to use your node only has to modify their configuration.json. Running an exit node from Tribler is even easier: it's a matter of setting one flag bit.

With that said, I will follow this up by advising not to change anything here. Getting these settings wrong, and/or injecting malicious bootstrap nodes, is the one way to really utterly and completely screw up. You may open yourself up to attacks (like the eclipse attack I mentioned earlier) or faults (for example, due to network partitioning) and/or accidentally instruct other Tribler peers to DDOS you. These issues go beyond Tribler crashing and head into ISP-level issue territory. That is why we really tightly control this stuff, typically only handled by people with a Computer Science doctorate (or something close to it).

In conclusion: if we need to, we can easily switch. However, these things are just too dangerous to put into a simple user interface of the average user.

P.S. Regarding independence and resilience, for scientific purposes, we have explored other bootstrapping mechanisms in the past (ex. [2017] abusing IRC for bootstrapping). Our Kotlin IPv8 implementation, for mobile phones, also includes BLE communication.