HTML5 steps closer to baked-in DRM support

HTML5 steps closer to baked-in DRM support

Summary: The first draft of a specification that would provide a hook for DRM systems to interact with HTML5 has been published by the web standards body W3C.

SHARE:

The web standards body W3C has taken the next step towards baking support for DRM (digital rights management) into HTML.

W3C last Friday announced the publication of the first draft of the Encrypted Media Extensions specification, which would provide a hook for DRM-systems to interact with HTML5.

The draft specification would apply to video, audio or interactive content marked with HTML5 media element tags. The specification defines an API that would provide access to content decryption modules (CDMs), part of DRM systems, when that media was played.

Earlier this year, 27 organisations — including the Electronic Frontier Foundation and the Free Software Foundation — described the proposed specification as "disastrous" and claimed it would change HTML to encourage the use of DRM. The W3C should reject the proposal, they said, on the grounds that DRM restricts access to content and contradicts W3C's stated goal of making the benefits of the web available to "all people".

Explaining the decision to publish the first draft of the EME spec W3C, chief executive Jeff Jaffe wrote: "While we welcome and value input from all parties, we intend to continue to work on content protection, and publish this draft."

The editors who drafted the initial EME spec are employees of Microsoft, Google and Netflix, and critics argue it is an attempt to elevate their business interests over the greater good of an open web.

But while opponents of the specification see it as encouraging the use of DRM and closing off parts of the web, Jaffe argued that failing to support content protection in HTML could result in wider access to premium content being lost altogether.

"Without content protection, owners of premium video content — driven by both their economic goals and their responsibilities to others — will simply deprive the Open Web of key content," he wrote.

"It is W3C's overwhelming responsibility to pursue broad interoperability, so that people can share information, whether content is protected or available at no charge. A situation where premium content is relegated to applications inaccessible to the Open Web or completely locked down devices would be far worse for all."

Jaffe also countered the argument that EME encourages the spread of proprietary, closed software in the form of CDMs, arguing that the API defined under EME would work with both proprietary and non-proprietary CDMs.

The EME proposal states that "implementation of Digital Rights Management is not required for compliance with" the specification. It says that sites that don't wish to protect content with DRM needn't do so, and can instead rely on the ability of the browser, or other user agent, to provide an unencrypted key to play the media.

The EME spec is an early draft not a final recommendation and will be subject to further revisions and consultation.

Topics: Web development, Software

About

Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • Security warning pops for this page

    Norton Internet Security tells me it's "processing W32.Harakit" as soon as I open this page. Better get somebody to look into it. Took the software 5-8 minutes to clean up traces, too.
    --Ed--
    EdTittel
    • Still Getting the Warning? Has anyone else gotten it?

      Hello Tim - we are investigating this for the site; has this happened to you again? After loading the page several times, I used PC Tools Security (also Norton), Glary Utilities and set IE10 to the highest level of security, but haven't been able to reproduce the W32.Harakit warning. Thanks.
      DavisSquare
  • No DRM in HTML5

    Mozilla's new JavaScript library that does HD video better than H.264 and lets content providers watermark videos should make DRM for HTML5 redundant. DRM is a failed technology which only hurts consumers and does absolutely nothing to prevent piracy. It should be stamped out of existence like the abomination it is.

    DRM needs to die.
    thezorch@...
  • Next Step: Open-Source DRM

    No standard is truly open until there exists an open-source implementation of it. Why should DRM be any different? It would also help ensure interoperability, in the same way Microsoft now relies on Samba to debug its own networking protocol stacks.
    ldo17
  • The Truth about DRM

    First, "Digital Rights Management" (DRM) is a marketing slogan. It is not a true description of the purpose of this technology. The actual purpose (and a far more appropriate name) is "DRE" (Digital Restrictions Enforcement). And, despite the endless lies to the contrary, "content creators" most certainly -will- "produce" digital content, with or without, such technology existing in the market (as long as any reasonable profit can be made). The false-assertion that movies, music, art, and journalistic-creations, will disappear without artificial, external, corporate-control, has been shown to be a red-herring time, and time, again. Also, (despite some of the most pernicious attempted deceptions) "DRM" offers absolutely no benefit, or security, to consumers, what-so-ever.

    Additionally, the history of the commercial Internet has repeatedly shown that any "standard" interface that "enables" the inclusion of externally-based, proprietary, code-engines in the standard Internet mechanisms is, frankly, a security, compatibility, and reliability, nightmare... just waiting to happen.

    Finally, everyone needs to look at the record, and agendas of those pushing the hardest for this addition to the HTML5 standard. Quite honestly, it isn't very flattering to the arguments for the inclusion of DRM in HTML5.

    These are the reasons that force me to conclude that this is far worse than just a bad idea.
    Gayle Edwards