There has been a lot of debate surrounding the idea that W3C was going to produce a standard that seemed to introduce DRM into HTML. Most of this has been about the desirability of DRM and issues such as the freedom of the web - but what about the technology?

The moral, economic and political arguments for and against the W3C apparently producing a standard for DRM on the web have been interesting but in the main fairly pointless. The fact of the matter is that, no matter what stance organization such as the FSF or "famous" people like Richard Stallman take, big companies are going to create mechanisms that enforce DRM and the only real question is whether or not it should be standardized. The W3C may be being pilloried as a traitor to the ethic of the "free web", but its job is to make sure that the web is standardized and not to enforce its freedom. 

Put simply, if there was no web standard for DRM then not only would there be proprietary web-based solutions, but we would construct apps that do the same job and this would remove a whole class of traffic from the web.

From a programmer's point of view it is much better to have a standard for DRM than a mess of proprietary schemes.

The W3C draft proposal Encrypted Media Extensions  (EME) is now available for everyone to read and comment on. What is interesting is that it only specifies the JavaScript API to connect to Content Decryption Modules (CDMs) which do the actual job of decryption.  The basic idea is to include additional features to the standard Audio and Video tags that allow you to detect encrypted streams and request keys so that the CDM can perform the decryption.

If you read the specification, don't be fooled by thinking that the "clearkey" scheme is being suggested as a real key exchange protocol - it is there just for debugging and to satisfy the need to have an open specification. Exchanging keys in the clear would make any DRM or crypto system very easy to break. 

What the standard specifies is the interaction with the CDM; not what the CDM does or how it works. In this respect the CDM looks very much like a proprietary plug-in, albeit one with a standard interface to the HTML page. In a very real sense the CDM is just a plug-in under another name and another interface. 

It isn't even specified exactly what the CDM does with its decrypted data. It can return decrypted media to the page or it can render it on its own using the facilities of the host system. Returning the data to the web page isn't particularly secure in that it would be fairly easy to capture the data and produce a DRM-free copy of the media. Rendering it directly to the hardware seems the most secure in that any capture would have to be performed at the system level. This is, of course, a long term problem with any DRM. If it allows you to access the media then what you can access can be copied - it's in the nature of a digital system. 

In addition, the CDM can perform any checks it cares to before decrypting the media. For example, it could insist on being used with a particular browser, operating system and even machine hardware not to mention, of course, user authentication. What this means is that the system can be used to restrict how the media is played back. It is highly unlikely that you or I would be able to create a web page that plays back DRM content even if the user has the credentials to access said content. It is also likely that open source players and even operating systems will be blocked from delivering the media because of the insecurities they bring to the game. And if you were to create an add-in that did anything to circumvent the DRM then you can be sure that the next version of the CDM would detect it and refuse to play.

As a result the EME holds little interest for most programmers and at best it simply allows the integration of proprietary delivery mechanisms into what looks like the web. The user will be able to navigate to DRM media content using the web, but it is highly likely that the decrypted media will be delivered by the CDM. 

Google has already incorporated EME into Chrome and Chrome OS. Netflix is currently building an alternative to Silverlight based on EME, and the Web Crypto API.