Main image of article Digital Rights Management in HTML5
In a recent blog “Implementing Video and Audio in HTML5,” I said that while HTML5 was a great step forward in terms of audio and video tags, different audio and video formats were required on a website in order to support all browsers. CopyrightThe heart of the issue is that no single audio and video format comes free from copyright, usage and patent restrictions. The result is that each browser vendor picks the format for which they have ownership or that they consider “safe,” i.e., with no legal issues lying in wait. We now have to add a major wrinkle to this situation: encrypted content that requires decoding before it can be played. Vendors encrypt content to control access to their material. The means to do this is embodied in various Digital Rights Management (DRM) schemes. All in all, this is a fairly controversial issue and has two very vocal camps:
  • Those who do not want browsers to provide any means to decrypt encoded content. They bristle at the whole concept of Digital Rights Management, calling it Digital Restrictions Management. They argue that it is giving in to the big media companies and that the implementation of DRM so far has been a failure. Aside from DRM’s use, they are happy to let the media content companies control their own material any way they want.
  • Those content providers -- for example, movie studios or online streaming services -- who want to be able to provide their content under some restrictions, e.g., you are a paying subscriber. They have legitimate business reasons to control and restrict the use of their content as it represents a huge portion of the company’s value.

Where We Are Today

Today, most browsers accomplish these kinds of tasks by means of plug-ins. However, as we know, HTML5 doesn’t allow plug-ins, and doesn’t provide a means of decoding the encoded content. To escape the issue of no plug-ins and lack of HTML5 support, many companies have chosen to implement audio and video function as an application and not as a website, e.g., Hulu and Netflix. By doing this they skirt the lack of the function in HTML5 and offer users a path to deliver the content.  The issue with this is that it takes us into a world where we have different implementations of the application for each desktop and mobile platform. I consider this a regression of the most serious type. For example, Netflix provides a “player” application for Microsoft, Google and Apple devices, but none for Linux or other desktop or mobile operating systems. On the broad topic of DRM some examples and issues with current implementation are:
  • iTunes content could not be shared (Apple had a proprietary content format to prevent unlawful usage).
  • Some Blu-ray discs won’t play on Blu-ray equipment. This is a consequence of rapidly adding additional DRM protection to ward off copying and leaving hardware and software players without the required decryption function.
  • The HDMI “protected path” is designed to keep non-compliant displays, TVs, projectors, etc., from playing certain content. However, HDMI capable systems under some circumstances will not play the content and will sometimes tell users their equipment is not HDMI compliant.
The issue with all of this is that the innocent and the guilty suffer together. How many of you have run into at least one instance where you were unable to play some form of media for which you were duly authorized, had the right equipment, etc.?

The Plan

Despite the poor history of implementing DRM, the World Wide Web Consortium (W3C) is proposing that HTML5 incorporate a means of accommodating it. They argue that if it doesn’t support DRM, more companies will escape via applications, as we discussed above. Providers of protected content will not accept unprotected formats and since HTML5 forbids the use of plug-ins (and thus they cannot escape browser limitation,) they must find a way to safely present their content. Basically the W3C fears that these companies will abandon the Web through the use of custom apps. The path that the W3C has chosen is not to directly implement any decryption in HTML5, but to provide a set of APIs in JavaScript that will allow any vendor to supply a module that will be invoked to decrypt content and supply it in a playable form. The proposal also defines license keys, which authorize users to access the content. Content owners would supply a common decode module for each browser at release. Whether these can be installed by the end user separately is not known at this time. With this scheme, instead of having a separate app for each platform, content owners supply the function for each supported browser and authorized user can then stream the content. It’s interesting to note that the authors of this proposal are from Google, Microsoft and Netflix, three companies who would benefit greatly by the approval of this standard because of their protected content or products that support protected content. These extensions are currently in the draft stage and can be found on the w3.org site under Encrypted Media Extensions.

Objections

Formal objection to adding these features to HTML5 has recently been put forward by the Electronic Frontier Foundation (EFF). The EFF, whose motto is “Defending Your Rights in the Digital World,” believes that this could (not would) stymie Web innovation and block access to content. Instead of it being a constructive addition to the HTML architecture, the EFF views it as an unwanted and unneeded special favor for Hollywood and the entertainment industry. In its view, the approach opens a Pandora’s Box of special features for special groups, and will create legal mandates that prevent legitimate users from publishing or using content because they fear repercussions from the content owners.

Conclusion

In my opinion this is a lesser of two evils situation where the basic argument is:
  • Don’t grant any special favors for DRM. As discussed above, this leaves us with each provider building an application to handle their content. The downside is that this leaves a number of people out-in-the-cold. A provider is likely to build applications for iOS and Android and perhaps Windows 7. This leaves Linux, Mac, Windows 8 and Windows Phone 8 users without a means to access the content.
  • This introduces a never ending cycle of restrictions on these users, which would be worse than having the function added to HTML5. That, as we have noted, would allow each content provider to build the function for each browser, and then be done.
This debate is far from over, but I cast my vote with the W3C for the implementation of this DRM architecture.