The proposal comes from authors at Google, Microsoft and Netflix, companies that stand to profit from the union of HTML5 and DRM. Others aren't so sure Encrypted Media Extensions takes the right approach: another Google employee has labeled the proposal unethical, and Mozilla has expressed concern that it won't work with open source browsers.
The W3C discussion of Encrypted Media Extensions includes a question from a Mozilla employee asking how EME would work in an open source browser:
...since the decoded video frames are stored in memory (as are audio samples) so that they can participate in the HTML rendering pipeline, how do you guard against an open source web browser simply being patched to write the frames/samples to disk to enable (presumably illegal) redistribution of the protected content? Or is it not required to guard against that case?
Netflix responded that this particular component of a browser would have to be implemented as closed source code but points to mobile devices with DRM built into firmware or hardware that still function in relation with open source software.
Ian Hickson, an HTML spec editor working at Google, levied a more serious complaint, calling the proposal unethical and stating: "proposal above does not provide robust content protection, so it would not address this use case even if it wasn't unethical."
Building DRM into HTML5 conflicts with the language's open source nature, and Encrypted Media Extensions seems incompatible with open source browsers. At the same time, it would give HTML5 video adoption a huge boost when it comes to copyrighted material. If a compromise was made and the code was closed off, the proposal could end up introducing a new plugin for HTML5 video DRM, thereby eliminating the appeal of HTML5.
With those strikes against it, Encrypted Media Extensions may not make it out of the proposal stage. Unfortunately, the tricky issue of DRM won't go away, and HTML5 will have to implement some solution to take over as the web's go-to streaming solution.