Making DRM practical

I was reading an article today, that said keep your best ideas for your products. This is probably one of those but since I don't have the resources to do it I'm hoping that Adobe, Microsoft, Oracle or Google read this or someone at their companies suggests something similar.

Digital Rights Management (DRM) is broken. As a concept it is brilliant, it allows you to move security away from the infrastructure and to the information. Security travels with the information no matter where it goes. In practice currently it is badly broken, it is too hard to implement and use. I have some suggestions for fixing it....


Data and information needs to move to be of any use. You can't just lock it up, and increasingly with Cloud computing, social media and world wide on-line collaboration - more and more data is moving to more places faster. For example GigaOM writes that documents are moving from being spreadsheets and word docs to be made up of Twitter messages and blogs. In fact I was reading this book that was entirely written on Twitter.

To be effective Digital Rights Management (DRM) needs to have the following properties:
  • Be really easy to use - that means both for the creator of information to apply DRM (or have it ideally applied transparently based on context analysis against policy) and for the consumer (to view and edit the information without any new software or new passwords, registrations etc)
  • Do not restrict the natural movement of information and collaboration between those who should have access
  • Secure - it must be able to restrict access to view, edit, control print, copy, even screenprint (using some automagic) etc. 
  • It must allow full tracking of what actions have been performed by whom, when and where on the information ideally with geolocation
  • It must be self contained within the information - there must be no new software, the DRM needs to be meta information that travels with the information always
  • It must leverage existing identity systems without requiring the creator nor the consumer to enroll and use new identity systems. No new passwords should be required, or certificate installation and no out of band transfer of credentials

    Problems with current systems

    Current implementations of DRM are hopeless. I tried to use Microsoft DRM with Office 2010 (which is leaps and bounds ahead of where it was previously) but guess what send it to a few people using MAC computers and they can't open it. Even Windows machines running Office 2003 or 2007 had a lot of problems and I had to go back to basic password based protection. Oracle's DRM is worse - you need to install software to even open a document. A friend was telling me about the 50 step process you need to go through to open a DRM document on the Sony e-Book reader - hopeless, no wonder 1 Click Amazon has 61% of the e-Book reader market

    A better solution design

    I believe that these requirements can be achieved today as they are already applied by other software. Some ideas on how:
    • Identity - use existing identity systems such as Google, Open-ID, Twitter, Facebook, MS Live-ID etc. Google already does a great job of this with using email address for sharing Google documents
    • Authentication - use the existing authentication in a federated manner - again leverage the above systems. Twitter has a great API implementation of this with oAuth. How about if all I had to do to protect a companies confidential documents (and twitter messages) was to enter a twitter id of people that should have access to it. They are automatically sent an invite link, they authenticate against Twitter to gain access
    • Role based access - Google documents, Gomockingbird etc have excellent and simple methods of choosing what access people should have. You should be able to request greater access by simply email, twitter etc
    • Tracking - you need to be able to be alerted (configurable) and report on all aspects of a DRM document e.g. I shared my HR database with my payroll provider I want to know who opened it, from where in the globe, at what time, what they did (read, edit etc). This should all be alterable and reportable. Dropbox does a great job of this e.g. you are emailed when someone joins your shared folder. This should be in syslog format so you can easily import it into a SIEM
    • Self contained - no software. This is probably the hardest part, but I have seen some very cool protections applied by PDF in the UK HMRC company tax return. This could simply be opened by Adobe acrobat reader. Alternately you could do it like through Google docs (including off-line mode) where all you need is a browser because you authenticate to gain access
    • Secure - again PDF, even MS DRM does a good job at being able to restrict view, edit, copy, print. There must be some auto-magic that for example stops the print-screen function or for really sensitive information (where you are worried about someone taking a photo of it when displayed on screen - a viewing window that moves at reading speed and the text randomly moves around the screen. Get the thinking hats on - this can be achieved
    • Context policy based - you should be able to tie your DLP system to analyse information and automatically apply DRM policies or request the user that they select who should have access to it. RSA DLP can already do this but with MS Rights Management Server (which is horrible). Alternatively you could use lower tech like Dropbox folders to have anything saved to particular folders to  have DRM policies applied. Also when information leaves your company e.g. email, FTP, internet, middleware - you could use an in-line DLP network device to analyse it against policy and apply DRM, this is especially easy with email if email is the DRM identifier - it can simply take the email addresses of the addressees (analyse them first against policy to see if this information should be going externally) and then apply e.g. read only DRM policy to the email and all attachments.


    DRM has had a really bad reputation and deservedly so, the current implementations of it are just terrible. But with some sensible user centric design in a few years it could be one of the most useful security technologies. It totally makes sense in a cloud based world where infrastructure security is becoming less and less relevant.


    1. Rakkhi, you hit the nail right on the head with this one. The key takeaway is there is little to no integration with the proper detect and correct security mechanisms. Current implementations are point solutions at best. Vendors need to work on a unified protocol and implement that from the ground up in operating systems and applications like PDF readers, SIEM and DLP. OpenDRM anyone?

      You touched on one key point though and that's the cloud and how it may be leveraged to do some of things you talked about. It is more than likely that this is a better place to implement DRM.

    2. You've done a very good job of outlining the problems that DRM faces, but I don't think you've solved the key one, self contained.
      The basic problem for DRM, like many other applications in this space in the past (eg games) is that the moment you give the complete product to someone, then they can subvert it. If I can open a document to read it, then digitally I can ALWAYS make a copy of that if I'm reading it on MY system, ie an environment that I control. You give the example of google docs in the self contained section, but that is precisely NOT self contained, you're effectively saying use an environment that google provides. In that scenario DRM can become possible, but then you're forcing users to consume your data in a manner that they may not want (in this case by using google docs). That might be acceptable in many scenario's, however, it is not self contained, and that is the real bane of DRM.
      To date we've seen that every single implementation of DRM that tries to meet this key requirement, fails, and in most cases badly. Even when using advanced cryptographic techniques to try and control what is going on, it always falls to the fact that if the data is consumed in the USERs environment, a third party can not control it. It's analogous to trying to write a secure application that is running on a backdoored kernel.

    3. Yes I agree that self contained is the most difficult issue but you don't need to make it impossible to get past just sufficiently difficult that the time and resources required are not worth the information contained in majority of cases.

      I belive now there are some ubicutous containers than mean that this is possible: namely the browser and as a lesser substitute widespread programs such as Adobe acrobat reader.

      Essentially the DRM file needs to remain encrypted and can only be decrypted via the container when the effective authentication, authorization and logging is performed. The meta data to perform this travels with the document while the container has the code to perform these functions. The container also enforces the security such as stopping print, copy, etc.

      Adobe acrobat protection already can do this to an extent - they just have not linked the authentication, authorization and logging to a cloud identity provider. Google docs achieves this for their files fairly well but with no offline capability. Office 2010 applications achieve this on platforms that can run this (i.e. Windows, not even really Mac) - again the identity link is the problem.

      So I think we are close, just needs these vendors to take the next logical steps

    4. I think that the success of the applications you mention is more that there are easier ways of subverting them right now. The issue as I see it though is simple, if I control the operating system, any application that you run has to make calls to me (the OS) and I can return what I want at that point. It's harder to do, but it's 100% foolproof.
      Ofcourse that then leads into questions of defense in depth. Sure by making it harder, the argument goes, you prevent the majority of users bypassing it. This is true, however, there are some situations where that doesn't work. I think the application space is an example, take adobe.
      Right now as you say the reader can prevent a number of things. Ofcourse anyone in the know just gets the writer to make modifications or manipulate the contents of a pdf how they want. Now let's say that Adobe stopped providing an easy way around manipulating pdf's. There would still be a lot of people who still wanted to use it as they want. One of those would have the capability to write something that intercepted the calls adobe reader makes to the OS, modify the OS's response and subvert the readers functionality. At that point the author simply distributes the software that makes it possible and now everyone else who is so inclined can take advantage of it.

    5. Sure in theory as you control the OS you cam bypass any protection. I would argue though the idea is to make this as time consuming and resource intensive as possible. Or maybe you are right maybe DRM can only be successful with no offline mode ie google docs model

      Also you are mistaken about being able to modify a protected adobe PDF doc so easily with writer. Give it a go password protect an PDF put print copy protection on it and try to edit it with whatever writer you want

    6. I believe that DRM can only be successful in the offline mode as you put it, but time will tell. So far i'm looking good :)

      As for the PDF comment, that's interesting. As you can probably remember I'm not very big into printing, nor into documents :) I've never actually used writer nor played with PDF's much at all but I'll have a quick look at some point and get back to you. Still I can't help but think that's still a good example, as trying to stop me printing sounds ridiculous, why wouldn't I just simply grab the screen as an image and print that?

    7. Hi, i have a project where i have to implement the DRM with documents uploaded by the users and other users download them. Please guide me how to implement DRM with my website. Many thanks.

      Hanan Ali

    8. Good answer to Hanan's queries about DRM in my post on Quora:



    Written by