Monthly Archives: November 2013

Why DRM is not a technical solution to privacy

Recently I’ve heard a number of people suggest that personal data might be protected using ‘digital rights management’, the same technology that some copyright owners use to ‘protect’ ‘their’ content (apologies for excessive scare-quotes but I think they are necessary in this instance). The idea is that content or data is transferred to the user in a proprietary format (often with encryption), which can only be played or used by related proprietary software or hardware and relevant decryption keys. Thus, in theory, the content ‘owner’ (or the individual data subject, in the privacy protection scenario) is able to ensure the content/data is only accessible to licensed users for a restricted range of uses. In practice, DRM content is invariably cracked and unlocked, after which it can be copied, shared and used without restriction.

I’m sceptical as to whether ‘DRM for privacy’ could ever really work as a purely technical fix to the privacy problem. As far as I can see, the proposals either amount to simple encryption of user data (which certainly has a role in protecting privacy, but has existed for years without being called ‘DRM’), or else they involve some additional policy proposal or trust arrangement which goes beyond the technology and enters into the contractual / legal / regulatory arena.

For instance, a recent DRM-for-privacy proposal from a Microsoft Research engineer Craig Mundie goes something like this. Personal data (e.g. health records) are encrypted before being sent to a third party (let’s say, a medical researcher) for processing. The encrypted package comes with some additional metadata wrapper, explaining the terms and conditions for use, and some kind of consent mechanism so the data processor can express their consent, whereafter the data becomes accessible.

This sounds nice in theory but in order to work, the terms would need to be legally binding and enforceable. Unless there is some sort of audit trail, and a credible threat for non-compliance, there’s nothing to stop the processor simply clicking ‘I agree’ and then ignoring the terms. Encryption only protects the data up to the point at which the data’s terms-of-use clickwrap is ripped open. And if the whole motivation for adopting DRM in the first place was that you don’t trust the entity you’re giving data to, it becomes pointless. Cory Doctorow put it thus;

For “privacy DRM” to work, the defender needs to be in a position to dictate to the attacker the terms on which he may receive access to sensitive information. For example, the IRS is supposed to destroy your tax-records after seven years. In order for you to use DRM to accomplish the automatic deletion of your records after seven years, you need to convince the IRS to accept your tax records inside your own DRM wrapper.

But the main reason to use technology to auto-erase your tax-records from the IRS’s files is that you don’t trust them to honor their promise to delete the records on their own. You are already adversarial to the IRS, and you are already subject to the IRS’s
authority and in no position to order it to change its practices. The presence or absence of DRM can’t change that essential fact.

Talking about encryption, ‘metadata wrappers’ and DRM makes Mundie’s proposal sound like a nice, stand-alone technical solution, but ultimately it relies on further legal, social and technical infrastructure to work in practice. All the encryption does is protect your data while it’s in transit, and all the terms-of-use wrapper does is let them know your preferences. Unless there’s something in current DRM-for-privacy proposals that I have missed – in which case, I’d be very keen to learn more. But I can’t find any more detailed proposals from Mundie or anyone else.

As well as being a little misleading on a technical level, I’m also suspicious about the motivation behind slapping the DRM label onto this proposal. Those who would like protect their business models with DRM have a vested interest in classifying any kind of socially useful technology which vaguely resembles it as such. That way they can refer to ‘enhanced privacy’ as one of the consumer benefits of DRM, whilst sweeping its more damaging aspects under the carpet.

Looking for a cloud I can call my own

Dusk Cloud Mountains, By DeviantArt User Akenator http://akenator.deviantart.com/ under a Creative Commons Attribution 3.0 License

The term ‘cloud computing’ refers to the idea that programs, processing and data storage can be run on a connected remote server rather than happening on your personal computer device. It was coined in the 1990’s by Irish entrepreneur Sean O’Sullivan, but didn’t achieve true buzzword ubiquity until the late 2000’s.

The term is still vague, despite attempts by the European Union to give it a concrete definition. To me, it simply means that the code I’m using and interacting with is happening on a computer that isn’t in my nearby physical space. But this lack of proximity to the physical location of the code can be worrying. Usually it means it’s happening on a server thousands of miles away that you have no control over. Can you trust that the code is safe, and not working against you? Who else might see your data when it’s stored in the cloud?

Despite these fears, most of us have embraced the cloud, using cloud storage providers like Google and Dropbox and installing mobile apps which store our data and process it remotely. But what is the alternative? One option is to store all your files and run applications on your own hardware. But many applications are cloud-only, and it is hard to make backups and integrate multiple devices (laptop, tablet, phone) without syncing via a cloud. Another is to encrypt all your data before you upload it to the cloud, but this can limit its use (the data needs to be decrypted before you can do anything with it).

A better alternative might be for each of us to have our own personal clouds which we can connect to via our personal devices. Personal clouds would be under our control, running on hardware that we own or trust. They could be hosted on lightweight, internet-connected devices kept in safe, private places – perhaps in a safety deposit box in your home. Or they might be hosted somewhere else – by a hosting provider you trust – and be easily packaged up and taken elsewhere if you change your mind.

Over the last few weeks, I’ve been trying to migrate away from my existing cloud storage providers (including Google Drive, Dropbox and Ubuntu One), and experimenting with running my own personal cloud. I’m trying out various free and open-source personal cloud systems, hosted on my own hardware (an old laptop), or on a hosting provider I trust.

Sceptics may say that this option is beyond the technical capability of the vast majority of users. I’d agree – without experience as a system administrator, it wasn’t simple to set up and maintain. But despite a few teething problems, it’s not as hard as I thought. With a bit of help and some improvements in user experience, running your own server could be within the reach of the average user. Just like the motor car and the personal computer, personal clouds don’t need to be fully understood by their owners.

One day, owning your own cloud might be as common as owning your own home (it would certainly be more affordable). And as personal data plays an increasingly important role in our lives, trusting the hardware it’s housed in might be as important as trusting the roof over your head.

I hope to blog further about my journey towards a personal cloud in the coming weeks and months…