Is it safe?
Yes, qBittorrent is safe to run in the sense people usually mean: it is ordinary open source software, its source is public, it is packaged by Linux distributions that build it themselves, and running it does not expose a machine to anything that running any other network program does not. The risk in peer to peer transfer is not in the protocol and not in the client. It sits in three specific places, and they are worth taking in order, because two of them are real and the one people worry about most is not the one that matters.
Where the risk sits, and where it does not
The risk sits outside the transfer mechanism, in decisions a person makes on either side of it. A client is a program that opens a network socket, asks other machines for numbered chunks of a file, checks each chunk against a hash, and writes it to disk. It has no way to run what it downloads, no interest in what the bytes mean, and no privileged access to anything except the folder it was told to write to. That is the entire security surface of the transfer itself.
- Check where the program came from, because a tampered installer is the one attack that has actually landed.
- Check what arrives on the disk, because a file from a swarm is a file from strangers and an executable from strangers is exactly that.
- Accept that the swarm sees your address, because peers connect directly to each other and that is the design.
Nothing on that list is unique to this protocol. The reason the question feels different here is inherited: in the Napster and Kazaa era, which began in 1999, the file sharing programs themselves were the problem, shipping with advertising, bundled toolbars and worse, and the reputation outlived the software by two decades. The open source clients in use now come from projects with public repositories and public issue trackers, which is a different situation entirely.
Risk one: where the program came from
Take the client from the project that makes it, because a compromised installer is the failure that has genuinely happened rather than a theoretical one. In 2016 the macOS installer for Transmission was tampered with on the project's own download server, on two separate occasions in the same year, and people who installed it in those windows received something other than the program they thought they were installing. The lesson is not that Transmission is unsafe. It is that the installer is the sensitive moment, and that a build offered by a site that did not write the software has nothing behind it at all.
The practical position is simple to state. qBittorrent, Transmission and Deluge each publish their own builds, and each project's own release channel is the only one with a reason to be trusted. On Linux the package manager settles it, because the distribution builds the client from source and signs the result, which is why the answer to what to install on a Linux desktop is usually whatever the repository already has.
Risk two: what arrives on the disk
What arrives on the disk is a file that came from strangers, and the protocol's verification says nothing about whether that file is what its name claims. Per piece hashing proves the bytes match the torrent. It cannot prove the torrent describes something harmless, because the hashes were computed by whoever made the torrent, over whatever they put in it.
The specific things that go wrong are old and dull. An archive contains a nested executable rather than the media it advertises. A file carries an extension that the operating system displays differently from how it treats it. A downloaded item includes a small program that asks to be run before anything will work, which is the oldest pattern there is. Documents and disk images can carry active content of their own. Whatever protection the operating system provides applies to these files exactly as it applies to anything else downloaded from anywhere, and the decision to open an executable is the decision that matters, not the decision to run a client.
Risk three: every peer in the swarm sees your address
Every peer in a swarm sees your IP address, and that is by design rather than by accident. A transfer is a direct connection between two machines: to send a piece to somebody, a client has to know where to send it. The tracker is told an address so it can hand it to other peers, and peers found through the distributed hash table learn one the same way. Anybody at all can join a swarm, connect to the peers in it and record what they see, and this is done routinely and at scale by organizations with an interest in who is in which swarm.
Two clarifications follow from that. Protocol encryption, which some clients enable by default, hides the content of the connection from the network in between, and does nothing whatever about the visibility of membership to the swarm itself. And services that place another network between a client and its peers change which address the swarm records; they do not change the fact that a swarm records one, and they move the question of who can see what to whoever runs that service. Both are worth understanding as mechanisms rather than as solutions.
What the protocol itself does, and what it cannot do
The protocol verifies and it does not execute. Every piece that arrives is hashed and compared against the 20 byte SHA-1 value recorded for it in the torrent's info dictionary, and a piece that does not match is thrown away and requested again from somebody else, so a peer that deliberately sends corrupt data wastes its own bandwidth and is eventually disconnected. There is no mechanism in the specification by which a peer can make a client do anything other than store bytes, and the terms involved, piece, info hash and info dictionary, are set out in the Glossary.
The honest qualification is that a client is still a network program listening on a port and parsing input from strangers, so its own defects are a real if unglamorous concern, and running a current build matters for the same reason it matters in a browser. If the actual goal is moving files between machines that all belong to one person, Syncthing is a different tool with a different threat model, because the devices there authenticate each other in advance and there is no swarm of strangers at all.
Deluge and qBittorrent, and what actually differs
Deluge and qBittorrent differ in how they are driven, not in how safe they are. Both are open source, both are built on the libtorrent engine, and both implement the same protocol with the same verification. qBittorrent is a single application with a window, laid out in a way that is familiar to anyone who used the popular clients of the 2000s. Deluge splits itself into a background daemon and a separate interface, so the transfer keeps running when the window is closed and the same daemon can be driven from a desktop interface, a web page or a console. Transmission takes the third position: a small engine of its own rather than libtorrent, a deliberately sparse interface, and a daemon that servers and network storage devices ship as standard.
| Client | Engine | How it is driven | What it is chosen for |
|---|---|---|---|
| qBittorrent | libtorrent | One application window, with an optional web interface | A complete desktop client with a familiar layout |
| Deluge | libtorrent | A daemon with a separate desktop, web or console interface | Running detached, and plugins that extend it |
| Transmission | Its own engine | A native application, or a daemon with a web interface | Doing little, on small hardware, without configuration |
The recurring forum question of which client is best does not have an answer, because the three differ in shape rather than in capability, and switching between them costs nothing but re-adding the transfers. Platform narrows it faster than preference does: on Android there are several capable clients, on an iPad and an iPhone there is almost nothing, because the store's rules leave very little room for this category. That is a property of the platform rather than a judgment about any program.