The (surp)rise of HTML5

Is HTML5 going to take over the DRM world, or are more established formats such as PDF likely to prosper?

Lately it seems that the DRM world has found HTML5 again, perhaps having tired of the various machinations of the XML world (a huge library of XML standard message formats is available at XML Standards Library), or perhaps because W3C decided to include an API  to discover, select and interact with DRM systems as well as with simpler content encryption systems.  It does not define what DRM may or may not be.  In fact the design of the system is to push DRM handling and management to the page authors.

You get a sudden feeling of the Gartner hype cycle attacking you.  We are in the Peak of inflated expectations!  Apart from proprietary implementations of DRM there is no industrial pressure to develop interoperable DRM standards.  In fact there is little pressure to standardize on a suitable document format – and that could be a more critical issue than a lack of other standards.

HTML5 has all the kudos of being the new (well OK, relatively new) standard on the block – before 2010 – its focus is on video, audio and canvas.  Most of us are still in print publishing so it looks like there will be plenty of time to adapt into the brave new world.  In the meantime we may settle for print publishing standards and avoid becoming the bleeding edge of technology.

Locklizard are sticking with the PDF format because it is well established and is the format of choice for the print publishing industry.  By comparison, HTML5 is rather new and unproven.

HTML 5 Viewers: Form matters

When you are building a standard for showing a video on a screen the most important factors are going to be the screen definition and format.  When you are building a standard for showing a document on screen or on a printer, you want them to be identical.  It’s no good having a dynamic re-sizing automatic reorganizing presentation system if it doesn’t look the same wherever you go.

Now this is probably heresy to the people who want to be able to access content on the mobile phone, but the reality is sometimes you simply cannot render an image onto a device that makes any sense.

Try, if you will, to get the painting “The night watch” by Rembrandt onto your mobile.  Use landscape format!  It is almost impossible to see anything of value, and the whole picture just swamps the screen.  Uh, hello – don’t blame Rembrandt for failing to foresee the 4 inch screen or paint a Peanuts cartoon.  If you ever get the chance go see the original.  It is truly spectacular.  And you can always say that is why you were in Amsterdam?

So back to my argument – form matters.  When you present a legal contract you have to be very clear as to what the order of paragraphs is, what is next to what, and so on.  If what you saw on the screen is different when printed out, then hello litigation.

The same is true of the Rembrandt.  It would be a travesty to change the format – the original is 11 feet by 14 feet and the figures almost life size.  It was painted to be seen at that size, not just impressive but magnificent.

So when we talk about applying DRM to documents there has to be some acknowledgement that the format must reproduce correctly.  And for the moment the only show in town is PDF.  That is the only standard that delivers a consistent form and format to the objects it handles. And that is why it will continue to be critical to the display of the printed document.  Because it not only has to feel right, it has to look right.

PDF Document Security & PDF DRM

Some people consider PDF security to be an oxymoron (a contradiction) ever since Elcomsoft developed the tools to remove the Adobe controls.  But that would be wrong.  The fact that the Adobe DRM controls introduced in the 90’s proved not as robust as they could have been had they access to today’s knowledge and toolsets (back in the 80’s encryption was strictly for banks and done in hardware because in software it was just impossibly slow) is just a problem of history, not competence.

Since the noughties we have had powerful enough desktop machines to be able to encrypt realistic amounts of data in sensible timescales.

And that has allowed us to develop far more sophisticated methods for implementing DRM over PDF than ever before.

Also, the decision by Adobe to publish the PDF specification as an International Standard (ISO 32000-1) created the potential for a market in alternative PDF rendering toolkits and the ability of third party DRM vendors to protect PDF source and impose DRM controls of their own by building the elements that they want to support and control into customised viewers rather than be constrained by the pre-built viewers from Adobe and as implemented in the browsers.

This may not sound important, even though it is.  Where you are trying to build security into a ready built application you are exposed to all the real and potential faults already in the application, and any hacks that work on the application.  But if you organize your own viewing and processing, which is not known to the attacker, then it is far harder to attack.

So using a different approach to how encryption is applied to the PDF document prevents historic password attacks.  And excluding forms prevents a number of attacks that try to connect to dangerous web sites to execute malware.