Goodbye passwords, goodbye DRM

At php|architect (and now at Python Magazine), we are often accused of using DRM to protect our PDF files. I have mentioned in the past that this is not true, but the accusations continue—probably thanks to two facts: (a) people have no idea what DRM is and (b) technology really, truly, sucks. Let me explain.

A PDF file can be encrypted using two passwords: an owner password and a user password. At least in theory, the difference between the two is that the latter can only be used to decrypt and access the PDF in accordance with the limitations that have been set with the former. So, for example, if I am the "owner" of the PDF, I can decide whether you can print it (and at which resolution), copy and paste text and figures from it, use it in a screen reader, and so on. These are the real DRM aspects of PDF protection—not the passwords themselves.

Our stamping system uses none of these DRM flags; as far as we are concerned, you are free to copy and paste, print, screen read and do whatever you want with the PDF as long as you comply with our license (which, essentially, means don't give it around—it's your copy, and only you can use it).

Unfortunately, the use of passwords has two significant drawbacks. First, most desktop search systems, like Google Desktop or Spotlight, are unable to index password-protected PDFs. Thus, customers have been complaining to us that our "DRM protection" makes using our PDFs inconvenient. Of course, I could point out that this is actually a limitation in the search software, and not something that we actively disable (why on Earth would we want to anyway?), but who's keeping track?

On top of that, Acrobat (or any other reader) do not allow users to add bookmarks or annotations to a password-protected PDF. Again, this is not something that we actively block, but simply a limitation in the PDF spec.

Why do we have passwords then? Primarily for two reasons. First, they reinforce the feeling of ownership that's associated with those PDF files. Second, they help protect the personal information that is stamped on the PDF files (like name and user account number) in case someone else gets a hold of them. You'll notice that I didn't mention security here—because although the password was making it a little more inconvenient, it didn't prevent some ill-intentioned idiot from removing all the protection and redistributing the file (after all, we need to allow people to read the PDF, and if you can read it, you can copy it, no matter how "strong" you think the protection mechanism is).

The reality is, passwords made a lot more sense five years ago, when we started publishing php|architect, than they do now. Back then, desktop search was limited (at best), and annotations were not yet part of the PDF spec. Back then, the public at large was not educated enough in the ins and outs of file ownership and, in my opinion, they needed all the reinforcements that we could provide.

Today, password protection has become a liability for us and a nuisance for our readers. It offers no real copy protection (and it never did), and it prevents our users from performing those tasks that matter to them. I have mentioned in the past that I have no sympathy for those who make the obliteration of DRM a crusade, mostly because by and large they seem to have no idea of what they are talking about, but real inconvenience for our customers (current and prospective) is something that I must take note of.

Thus, as we celebrate the fifth anniversary of our publication (has it really been that long?), we have removed all password protection from our PDFs. This means that every PDF you download from our sites (that is, from both php|a and PyMag) starting from today will no longer require a password for opening—including any product that you have purchased from us in the past and that you download again after tomorrow.

I thought this would be a difficult decision to make, but in the end it felt like the smart thing to do, both from a business perspective and from a technical point of view (encryption costs a lot of CPU cycles on our servers!). We've got a lot more surprises coming down the pipe... stay tuned!