Tribler is a free and open-source file-sharing app for Linux, MacOS, and Windows. It adds something unique to the BitTorrent peer-to-peer protocol: onion routing. Onion routing, best known from the Tor Browser project, is a network routing scheme that relays connections via multiple proxies. Tribler encrypts your connections in layers, so that each relay proxy only knows the IP address of the next and previous hop in the routing chain. This system can help provide more anonymity and obscure what you’re downloading and from where from prying eyes.
I’ve followed the development of Tribler closely over the last two years. In this article, I’ll discuss how Tribler works, which parts of it are anonymized and which broadcast what you’re doing in the clear. Tribler features solid core technology, but the project’s mixed goals and priorities don’t live up to its user expectations of privacy.
Tribler is a complicated piece of software, and it won’t protect your anonymity if you use it wrong. ‘Using it wrong,’ unfortunately, includes using some of the program’s features at all; and using others with the default configuration! I recommend that you take the time to read this article in its entirety before you consider using the software.
In traditional peer-to-peer (P2P) file-sharing, two devices connect directly to each other to exchange data. The devices discover each other using either a central tracking server or through the Distributed Hash Table (DHT); collectively called peer exchanges. A tracking server is a web server that keeps track of which IP addresses that offering a given file (seeding) and who wants to download the said file. The DHT serves a similar role, but instead of using a server; the same information is jointly maintained by the participating P2P clients. Anyone who wants to monitor who is downloading or uploading a given file can query public peer exchanges for a list of IP addresses that have expressed interest in it. There is no anonymity and everything happens in the clear.
Some BitTorrent clients have an option for encrypting the P2P data transfers, but the peer discovery process through the exchanges still happens in clear-text. The option provides some obfuscation, but it’s an entirely false sense of privacy. Correlating your observed peer-discovery queries followed by large encrypted data transfer isn’t rocket science.
Tribler also encrypts connections between peers, but it does so using ‘Tor-like’ onion routing. The data to be transferred is wrapped in layers of encryption (like an onion). Each layer includes a source and destination address pointing to the previous and next relay in the chain. This scheme enables each relay to forward packets in a chain without knowing who is downloading something, what they’re downloading, nor who is sharing the file.
Tribler applies the same principle to connections to peer exchanges. Queries and responses are shuffled around by onion routing. It has an internal DHT used for in-network file sharing. It also uses exit relays that can forward requests to the DHT network used by most other BitTorrent clients.
Anyone monitoring your network traffic can tell that you’re using Tribler and that you use BitTorrent. It does nothing to hide these facts from potential monitors. It crucially helps obscure what you’re using them for, however. The BitTorrent protocol and Tribler are legal in most jurisdictions, but they may be considered to be an illegal network-addressing obfuscation tool in a few places.
Similar to the Tor Project, Tribler has super peers known as exit relays. Exit relays are clients configured to allow data transfers and peer exchange traffic to exit from the onion-routed network onto the public internet. These exit relays bridge the Tribler onion network with the greater BitTorrent network on the public internet.
These super peers quickly accumulate tokens in the Tribler bandwidth economy, but at a significantly increased exposure to legal risks. I’ll discuss the concept of the bandwidth token later in the article. Tribler obscures what and where traffic is going into its network from the exit relays. However, a large-scale monitoring effort of the internet — hello, NSA! — could still correlate the timing of unencrypted traffic going into an exit node with the obscured traffic it routes into the Tribler onion network. Yet, it takes only a single click in Tribler’s settings dialog for your computer to become an exit relay too! Yikes.
The exit relays also reveal a flaw with Tribler’s default configuration. The exit relays are also considered to be regular relays. By default, Tribler is configured to only use a single relay. Your one and only relay node, as per the default configuration, is also the exit relay.
For onion routing to be effective, you need to relay through a chain of at least two other nodes. The first node doesn’t know the contents of the encrypted traffic, and it knows your IP address and the IP of the next node in the chain. The second node knows the first node’s IP address and the IP address of the seeder. Neither the seeder nor the second node knows the downloader’s IP address! No one knows more than two out of three bits of information in the transfer chain; namely who’s downloading, who’s uploading, and what’s being transferred. For comparison, the Tor Onion network uses two intermediary relays plus the exit relay.
Every user is a relay by default, and there’s no [easy] way to opt-out of it. Your client will only ever acting as an intermediary relay that relays end-to-end encrypted connections (unless you opt to be an exit relay). Yet, there’s little demand for other relays as the default configuration only uses the exit relays.
When you’re using Tribler you’ll likely only ever download through the exit relays. As discussed above, the exit relays know your IP and what you’re downloading! I’m not revealing a new flaw in the design of Tribler. The project website explains the difference between single and multiple relays, including graphs and everything. I’m uncertain why the project promotes its onion routing capabilities, but don’t take advantage of them by default.
You can at any time go into your Tribler settings and change the number of relays from one to three. The option is there, but it's not set by default. The tyranny of the default means most users will use Tribler, and practically be at the mercy of the exit nodes not to monitor their activities. It’s not entirely clear to me why the more anonymous three-relay setting isn’t the default configuration.
The Tribler software depends on third-party software dependencies like libtorrent for parts of its core networking technology. The Tribler project’s test suites don’t proactively try to detect unexpected network connections or other information leaks. Bugs that compromise your anonymity in Tribler or its dependencies could pop up at any time without the project maintainers noticing it. The test suite could be more proactive by including a mock Domain Name System (DNS) server and a review of which domain names the client tries to contact. Similarly, it could log connections to look for unexpected or unencrypted traffic, e.g. unencrypted DHT lookups or connections to web servers. There have been several examples of DNS leaks and unencrypted connections leaking out of Tribler.
For instance, Tribler added a new feature called the Torrent Checker in Tribler version 7.3 released in . The Torrent Checker would check the swarm status of randomly selected torrents in the Tribler discovery service. Unfortunately, the new feature didn’t utilize Tribler’s onion routing for the health checks, and it would simply query DHT and tracking services for the status of random torrents. To services that track DHT queries, it would appear as you were interested in downloading these random torrents. I’ll discuss the Tribler discovery service later in the article.
The Torrent Checker was seriously ill-conceived, you were opted in by default, and there was no off-switch for it on the settings page. This feature could get you into serious legal troubles, disappeared, or even result in the capital penalty (depending on your jurisdiction, of course) over illegal materials you never downloaded or even knew existed. For example, Tribler could randomly check on the status of a randomly selected file by reaching out to a BitTorrent tracking server specializing in male-focused adult-themed content. Homosexuality still carries the capital penalty in ten countries around the world, and some of them do extensive internet surveillance.
The Torrent Checker began proxying DHT requests through the Tribler anonymizing network in Tribler version 7.5 which was released in . The feature would still connect directly to web tracking servers, however. Concerned users complained about “DNS leakage” from resolving the tracker server domain names; without noticing the plain-text HTTP connections to the same trackers. This was partially fixed in Tribler version 7.6, released in , when it also began checking tracking servers over its onion network. However, the feature would still leak some DNS lookups and didn’t work at all with the Torrent Checker.
The last leaks were fixed in version 7.10; released in . It took the Tribler project two years to silence the talkative Torrent Checker feature. Online services like I Know What You Downloaded would naturally attribute all these DHT requests to your IP address. This made you appear as a BitTorrent power-users who downloaded all sorts of random material through the protocol.
Tribler doesn’t support the webseed BitTorrent protocol extension (BEP 19) despite having limited support for TCP/HTTP tunneling. BEP 19 lets torrents specify web servers that can help seed torrents when the BitTorrent swarm isn’t up to the task, e.g. when there are few or no seeders. The TCP/HTTP tunneling in Tribler is exclusively used for contacting tracking servers, and exit relays reject non BitTorrent encoded (bencoded) responses. This feature is important for ensuring that unpopular and newly released torrents work. The Humble Bundle store, for example, distributes its downloads through webseed-backed torrent files.
There’s an elephant in the room, and it’s time to address it: Tribler’s bandwidth token system. You pay tokens to relay downloads through other users and you earn tokens by uploading to other Tribler users and by being an intermediary traffic relay for other users. It costs more tokens to relay through multiple relays, so a 1 GB download costs 3 GB through three relays.
BitTorrent clients traditionally track your sharing ratio: your upload versus download ratio. You can increase your sharing ratio by leaving the client running and hoping someone will come by and want to download from you. It’s a zero-sum game. The more people who download a file the more people share it and a decreasingly smaller and smaller part of the file may get downloaded from your client.
Tribler down-prioritizes what it calls “selfish” clients; which it defines as clients with a negative 20 GB token balance. (You achieve this balance after downloading roughly 6,6 GB via three relays.) Most clients will use the default settings, so most users simply pay the exit relays without needing to route through any other relays. It’s nigh impossible to increase your token balance unless you’re an exit relay. I believe most people simply abandon the program at this point as it seemingly stops working.
The only source of new bandwidth tokens is the 20 GB granted to new users. The network depends on ‘mining’ an unending stream of new clients who’re willing to join the network before their clients eventually slow down and they stop using it. It’s much faster and easier to reset your Tribler instance to get another 20 GB worth of tokens than it is to earn them legitimately by relaying traffic in the network. Your token balance decreases faster over time due to the token cost for protocol upkeep than you earn tokens for relaying traffic for other users.
The token balances are a cryptographic blockchain signed by the other participants you communicate with in the network. The blockchain records the amount of data transferred, a cryptographic hash representing the participants, and the time of the transfers. It doesn’t record what was transferred. However unimportant metadata like this may appear, there have been countless examples of someone managing to stitch together data like this with other data to glean more information than what is apparently there.
A possible fix would be to increase the default number of relays to three. As discussed, this would make anonymity stronger, and also help circulate bandwidth tokens to more peers throughout the network. It wouldn’t fix the imbalance of exit nodes accumulating ever more bandwidth tokens, however.
Jamie King interviewed Bram Cohen, the inventor of BitTorrent, about this topic on an episode of the Steal This Show podcast (audio via Magnet or YouTube). The pair discuss how maintaining a community/scoreboard based on sharing ratios and bandwidth accounting is outdated. By definition, everyone can’t be above average; it’s nearly impossible to maintain a 1:1 sharing ratio, let alone exceed a 1:1 ratio. Someone must incur a negative bandwidth balance for others to get a positive balance.
The pair also discuss how private trackers (usually belonging to closed groups of file-sharers) should instead incentivize and reward people for sharing rare files. They argue that making rare files available to the network over time adds more value to the network than the raw bits transferred. You can find similar thoughts on rewarding users for sharing rarer files in the Tribler mission statement, but it has yet to materialize in the client. You currently lose credits due to the cost of paying for the protocol overhead by seeding unpopular torrents.
You need to share three times as much data as you download when using Tribler to pay all the relays. The problem is that no one wants to download from a Tribler client. You don’t earn any tokens for uploading through exit relays to other BitTorrent clients. You even lose some credits on the protocol overhead that’s relayed through other Tribler users. A known problem Tribler developers refer to as “token blackholing.”
Tribler knows it has an undersupply of exit nodes, yet not even other Tribler users will download from your Tribler instance. The most common solution to a network routing problem is to select the shortest route. Tribler also prefers the shortest relay route as it can be assumed to be faster. Therefore, Tribler prefers downloading through an exit relay as it’s both faster and cheaper than downloading from other Tribler users over multiple relays. Tribler could help mitigate this problem by making the client prefer transferring internally in its relaying network despite the higher “token cost.”
This brings us back to the topic of the exit relays. The whole system is incredibly reliant on its exit relays. As discussed, they can de-anonymize every user and know what everyone is downloading (unless you increase the default relay count). The exit relays can also conceivably manipulate what you’re downloading.
The exit relays are perfectly positioned to carry out a monster-in-the-middle (MITM) attack against your BitTorrent transactions. As discussed, BitTorrent works using by discovering other peers by querying either the DHT or tracking servers. Tribler relies on exit relays to query the public DHT network and tracking servers on your behalf. It queries for the BitTorrent Info Hash (BTIH) of a torrent you’re interested in downloading. The BTIH is an SHA-1 cryptographic checksum of the desired torrent file.
Unfortunately, the SHA-1 algorithm has been known to be weak and spoofable since 2004. It’s now considered achievable to construct a file (potentially with a deanonymizing or otherwise malicious payload) with the same SHA-1 has as a target file.
A determined attacker, or in the case of BitTorrent — a determined lawyer representing copyrights’ holders, can set up a Tribler exit relay and monitor what people are downloading. They could also intercept and reply to any DHT or tracking server queries with peers they controlled. These peers can then send a torrent metafile containing a payload that the BitTorrent client would proceed to download. The file would pass the built-in file-corruption and checks in the BitTorrent protocol (all relying on the SHA-1 of the BTIH).
This problem isn’t unique to Tribler and affects all BitTorrent clients. However, Tribler is uniquely susceptible to it because of its reliance on unknown intermediaries. The BitTorrent protocol version 2 addresses this vulnerability by upgrading the hashing algorithm used for the BTIH to SHA-256. Tribler doesn’t yet support version 2 of the protocol despite being more at risk than typical BitTorrent clients.
Tribler offers improved anonymity when downloading torrents. However, it also comes with built-in features for searching for and discovering new torrents. These features do not provide any anonymity. The infrastructure for encrypting and relaying queries is there in the client, but it’s not used for these purposes.
Searches are sent from your client to other Tribler users in cleartext. Likewise, your client may receive and respond to other users’ queries in cleartext. Anyone monitoring your network can see what you search for and what search results are returned to you. They cannot, however, see what — if anything — you choose to download. They can infer that any large data transfer starting immediately following a search query is for one of the returned results.
The search is maintained by a distributed index of torrents maintained by Tribler users. It’s similar to the DHT, but contains richer metadata about each torrent. Search queries are by default filtered against an optional family-friendly filter. The filter discriminates against some ethnicities, hair colors, and sexual identities. I’ve sent a change request to the project to address that issue.
Tribler also has a system for content discovery and creator channels. Neither creating a new channel and sharing content, nor subscribing to an existing channel is anonymous. Tribler doesn’t communicate that search and its other discovery methods aren’t anonymized. Project maintainer Vadim Bulavintsev said the following in a discussion about Tribler not anonymizing these features:
This comment shows the stark contrast between user expectations of privacy versus the project’s own wants and goals. The Tribler client never communicates this to the user. No one expects that some parts of a privacy-focused software project won’t feature the same privacy-preserving technologies as the core software. These features need to be made private, or otherwise come with large obnoxious privacy warnings.
The whole channels system is a leftover from the late 2000s when there were multiple entertainment-focused BitTorrent clients with built-in video streaming capabilities. These clients sprang up to address the — at the time — prohibitively expensive prospect of hosting and sharing videos. These clients had channels and the idea was they could be a video platform for creators. Then YouTube came along and offered free video hosting and monetization opportunities for creators, and ease of use for the masses.
Tribler channels are unappealing to potential creators looking to distribute their works. They’re difficult to manage; and it’s unclear how you back it up, move it between devices, or even share your channel with others. There is, for example, no way to get a link to it or any other sharable identifier for use on social media.
It’s also unsuitable for dissidents or other groups looking for more private and secluded places to share on the web. The lack of anonymity makes it wholly unsuited for those groups. Which leaves behind a feature that struggles to justify its existence. From the mostly stale channels list, I gauge there is no interest in it either. Not even Tribler itself uses its channel feature, or indeed their own network, to distribute software updates to Tribler.
The network overhead of maintaining the search index and updating channels is deducted from your token balance and paid out to other peers. Due to how the DHT is organized and replicated, this rewards long-lived peers (always-on PCs) at the expense of shorter-lived sessions (laptops). This is why you can experience that the token balance is gradually decreasing over time even when you’re not downloading anything.
In my experiments, disabling the search and channels features significantly accelerates how fast your tokens vanish from your balance even when you let the client sit idle. In theory, the token balance should then only ever increase as you only participate by relaying traffic. However, I’m seeing the opposite and the token balance goes down almost twice as fast.
There are no options for disabling these features in the settings screen, but they can be disabled through the configuration file. Note that the client won’t hide these features and that it prints error messages when you try to use them and during start-up. You can compare this prepared configuration file to your own to learn how to disable these features.
Assuming you increase the default relay count setting, then file transfers in the current Tribler release, version 7.10, work well and can be considered to be more private than not using Tribler. I’ve paid attention to releases for the last three years, and this is the first version that has earned this verdict.
In one of my first trial runs of Tribler, I created a torrent on one PC that ran Tribler, and tried to download it using Tribler on another PC. However, the file transfer never started — the downloading client was never even able to fetch the torrent file to join the swarm. After a few more tests, I found that Tribler couldn’t download from other Tribler users using just the torrent’s Magnet link. This worked fine when downloading from other BitTorrent clients, just not internally inside the Tribler network. I reported the issue and it got fixed in Tribler version 7.10 (released in ). To me, this issue revealed that even the core functionality wasn’t well-tested.
The project’s recent history shows us that you need to carefully scrutinize each release before adopting it. There might be another Torrent Checker feature added in the future, or a bug/regression could sneak up via libtorrents and other core dependencies. You can use Tribler in combination with a Virtual Private Network (VPN) to reduce the impact of any future problems.
The project’s website features a prominent warning below the download buttons (shown below). Neither the website nor the client itself does an adequate job of warning you against using specific features like search and channels. The option to become an exit relay should be removed entirely from the settings screen. It’s way too easy to turn it on without fully understanding the consequences.
So, should you use Tribler to anonymize your BitTorrent downloads? Undoubtedly. Tribler’s shroud of privacy and layered encryption is much better than doing nothing to obscure what you’re downloading. You should understand that the client isn’t perfect and the level of privacy it offers varies from version to version. You should steer clear of any but the core file transferring features.