26 Oct 2009

Your BitTorrent client probably has DRM in it, even if it's Free software. Torrent files (.torrent) may contain a special, but unofficial, "private" flag. When it does, clients are supposed to disable decentralized tracking features, regardless of the user's desires. This is a direct analog to the copy-prevention flag that PDFs may have set, which tell PDF viewers to cripple themselves, except that your Free PDF reader is actually more likely to ignore it.

It's impossible to simply open the torrent file and turn off the flag. The client has to be modified, fixing the purposeful defect, to ignore it. Note, simpler clients that don't have these features in the first place don't have this problem, since they don't have any features to disable.

The private flag exists because modern BitTorrent trackers can function without a central tracker. If the central tracker is down, or if the user doesn't want to use it, the client can fetch a list of peers in the torrent from a worldwide distributed hash table. It's one big decentralized BitTorrent tracker (though any arbitrary data can be inserted into it). Clients also have the ability to tell each other about peers when they are doing their normal data exchange. Thanks to this, clients can transcend central trackers and join the larger global torrent of peers. It makes for healthier torrents.

Anyone who knows a few peers involved with a torrent can join in, regardless of their ability to talk to the central tracker. But private tracker sites don't want their torrents to be available outside to those outside of their control, so they proposed an addition to the BitTorrent spec for a "private" flag. Clients with decentralized capabilities are advised cripple that ability when the flag is on, so no peer lists will leak outside the private tracker. This flag was never accepted into the official spec, and I hope it never is.

Unfortunately the private trackers set an ultimatum: obey the private flag or find your client banned. The client developers fell in line and, and as far as I am aware, no publicly available clients will use decentralized tracking while the flag is on. At one point, the BitComet client ignored the flag and was banned for some time until it was "fixed".

The private flag wasn't placed in front with the rest of the metadata where it belonged. It's intentionally placed at the end of the torrent file inside of the info section. This means that the flag is part of the info_hash property of the torrent, which is the global identifier for the torrent. Unset or remove the private flag and the hash changes, creating a whole new torrent without any seeds.

This is DRM, an artificial restriction imposed on the user. It's insulting. Users should be the ones that control what happens with their computers. The reasonable approach to a private flag is that, when the private flag is enabled, decentralized tracking is turned off by default, but can be re-enabled by the user should they desire. That way the desired behavior is indicated but the user has the final say, not some unrelated website operator.

I rarely use private trackers, since they are nearly pointless, but I still find this private flag set on public torrents, probably from someone simply reposting the torrent file from a private site. It's annoying to run into. It makes the torrents weaker.

Debian, which is my distribution of choice, is generally good about removing DRM from the software it distributes. For example, the PDF readers in the repositories have their DRM disabled (i.e. xpdf). So why not do the same thing for all the intentionally defective BitTorrent clients?

I went on the Debian IRC channel on Freenode and brought up the issue only to find out that everyone thought a little DRM was reasonable. So then I filed a bug report on it, which was simply closed citing that the DRM is a beneficial "feature" and that removing the intentional defect would make the clients "poorer". They also insisted that it's part of the spec when it's not. I'm really disappointed in Debian now.

Now, I could modify a client to ignore the flag, but it's not useful if I am the only one not running DRM. It takes two to tango. A client used by many people would have to be fixed before it becomes beneficial.

So when someone asks for an example of Free Software or Open Source software with DRM in it, you can point to BitTorrent clients.

10 Oct 2009

I started getting Asian spam in my comments in the last couple days. If you are subscribed to the comments feed you probably noticed this. The spammer was manually filling out captchas, so this wasn't a bot but rather a patient human being. Getting tired of removing these, I set up some filters to silently drop messages that fit certain criteria. By "silently" I mean the server tells the client everything went fine but the comment never actually gets written to the database.

The spammer gained nothing except annoying us because all links in comments get a rel="nofollow" attribute, which tells search engines to ignore it. That, plus small readership and captcha-solving gives little incentive for spamming.

Well anyway, while I had my sleeves rolled up and my hands on the code I decided to make some upgrades I have been wanting to do. The e-mail address is no longer displayed (stupid idea in the first place) but instead used for a Gravatar image. You can also specify a home URL, which will be linked from your name. This makes my comment system work very similarly to what you find around the web, except that I don't require anything from you but a captcha and a comment.

I also fixed a small usability issue: when you preview a comment now it takes you right down to the form rather than leaving you at the top of the page. The back-end database was also adjusted from the original pollxn design to scale better as the website grows.

Now, Gravatar is a neat concept but I have two complaints. One, I don't like centralized systems. It's a single point of failure and a single point of control. It has privacy issues. It's anti-web. It's inelegant. Decentralized systems built around self-enforcing protocols are more robust and democratic.

Luckily, a decentralized version does exist! It's a specification called Pavatar. The avatar is tied to a URL rather than an e-mail address. However, it's a bit less flexible, since it needs to remain simple on the server side. It's harder to set up and I doubt 99% of the users on the web would be capable of doing it. What would help Pavatar gain a wider audience would be Pavatar provider services. Hmmm...

So, I think might switch it to Pavatar sometime, with a possible fall-back to Gravatar. That takes significantly more work to set up than Gravatar does, so it's a future project. And, well, no one uses it yet either. I actually thought the project was dead until just now because their website was down the first time I visited it a couple months ago.

My second complaint is that Gravatar incorrectly assumes e-mail addresses are not case-sensitive. The domain part is, but the alias part is not. These two addresses could technically arrive to two different e-mail inboxes,

chris@example.com
Chris@example.com

Pretty much every e-mail server will treat these as the same address as a convenience, because treating these differently would just be confusing, but it's not necessarily the case. Gravatar specifically says to hash the e-mail in lowercase form, so the unique address Chris@example.com can't be used with the service.

So, go ahead and play in the comments a bit.