Is EME just an <object> tag with encryption?

Question

This is a touchy topic. I have tried to present the context, but keep the question focused on the technical question rather than a debate of right-versus-wrong. Please support whichever side of the debate you prefer with your wallet and feet, not in the comments or answer.

---

The Encrypted Media Extensions draft dated 7 January 2014, the drafters insist (my emphasis):

This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification.

Instead, they say:

The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.

But I assume that EME is what everyone is up in arms about when they say that the W3C 'are introducing DRM' to HTML 5.

---

My (limited) understanding of the spec is:

It defines a generic hook for authenticating access to a media file on an HTML page. The authentication would be handled server-side not client-side ("leaving application functions such as authentication and authorization to page authors") but via HTTP ("requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication"). One obvious use, and the motivation for EME (citation needed?), is consumer-oriented DRM. [1]

The intended effect is to replace client-side media wrappers (Flash, Silverlight...) with a simple hook into server-side authentication providers.

[1] Could there be other, security-oriented applications of EME?

---

So, assuming I got all that right, am I correct that this...

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="550" height="400" id="movie_name" align="middle">
    <param name="movie" value="movie_name.swf"/>
    <!--[if !IE]>-->
    <object type="application/x-shockwave-flash" data="movie_name.swf" width="550" height="400">
        <param name="movie" value="movie_name.swf"/>
    <!--<![endif]-->
        <a href="http://www.adobe.com/go/getflash">
            <img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player"/>
        </a>
    <!--[if !IE]>-->
    </object>
    <!--<![endif]-->
</object>

(where the SWF file imposes DRM via internal, client-side code and/or hooks to server-side authentication, executed in the browser via Flash)

would be replaced with something like this (adapted from html5media.info)? [2]

<video src="movie_name.mp4" eme="some_drm_key_or_something_here"
width="550" height="400" controls preload id="movie_name"></video>

[2] But where is the file stored, and for how long?

---

TL;DR Ignoring whether or not DRM is ethical/good business/a pain, is EME a means to formalise a vendor-neutral, server-dependent, no-plugins-required mechanism to authenticate access to media files? Implementation could, for example, add attributes to existing HTML5 media tags, and as long as the browser could a) authenticate and b) play the file format, the media would be viewable.

Answer 1

Yes.

And No.

First let me explain the NO.

EME does in its essence not define a DRM technique: it defines an API to access DRM modules in the browser (or in the operating system, or in a browser plug-in). This means the user still has to have access to the required DRM method. If the browser vendor does not support it, you will need a plug-in. (Also, it's extremely unlikely that vendors will include support for the DRM of their competition: Google Chrome has support for Google's Widevine, IE11 had support for Microsoft's PlayReady. I would be very surprised if Firefox would choose to support any of these.) Browser plug-ins however do not offer a valid option: they do not exist on mobile devices. It might be possible some browsers will allow apps to add DRM, but think of the security risks this would bring. The same risks go for plug-ins by the way. Think of the Adobe Flash security horrors.

Now on the YES front: there is a mechanism which is included in EME that should be supported by ALL browsers in form of clearkey. However the purpose of clearkey is to be able to test EME applications. Practical use will be limited unless the big media studios would see it as a proper DRM (which they don't).

So to round up:

In practice, EME is more pain than good. It brings more fragmentation for broadcasters since all browsers will support their own DRM schemes. This means the user will be bothered to either install insecure plug-ins and add-ons or to use certain specific browsers or devices to access content. At the other side of the spectrum, broadcasters will have to publish content using multiple DRM mechanisms, which will strangle them in license fees.