Proposed Encrypted Media Support in HTML5 Sparks DRM Debate on W3C Mailing List
A proposal drafted by Microsoft, Google and Netflix to add support for encrypted media playback in HTML5, has sparked a debate on the W3C (World Wide Web Consortium) HTML public mailing list.
The document is entitled "Encrypted Media Extensions v0.1" and was submitted to W3C's HTML Working Group for review on Tuesday. Its authors propose an extension to the HTMLMediaElement interface that would facilitate the decryption of protected content.
"Many content providers and application developers have said they can't use <audio> and <video> because HTML lacks robust content protection," said Adrian Bateman, one of the people who drafted the new proposal, on the mailing list. "Without this functionality, they cannot move their apps to the web platform."
Companies like Netflix need to protect the content they are licensed to distribute. Because of this, their current platforms are built around plugin-based technologies like Flash or Silverlight, which support DRM (digital rights management).
The Encrypted Media Extensions proposal doesn't aim to implement a comprehensive DRM system in HTML5, but to provide a simple mechanism for exchanging content decryption keys, its authors said.
However, some people don't think the standard should include such a feature. "I believe this proposal is unethical and that we should not pursue it," said Ian Hickson, the maintainer of the WHATWG (Web Hypertext Application Technology Working Group) HTML5 specification, in response to Bateman's argument. The WHATWG HTML 5 specification serves as basis for W3C's HTML5 standardization efforts.
Hickson didn't elaborate on why he considers the proposal unethical but said that it wouldn't provide robust content protection, so it wouldn't solve the problem content distributors have anyway.
Even though the proposal doesn't provide a complete DRM solution, some people feel that it is designed to allow such systems to be built into browsers at a later time. However, implementing something like this would be very problematic for open source vendors like Mozilla.
"A browser like Mozilla is *legally prevented* from actually implementing DRM, because they have to reveal all their code, including the decryption code that contains the secrets you use to decrypt," said Google Chrome team member Tab Atkins Jr., in a reply to the mailing list discussion. "We should not be attempting to put anything in HTML which won't be implemented by one of the major browsers."
At the moment, the proposal has an unofficial draft status which means that it is a work in progress and is open for comments from the public.