Re: Technical Review of EME (DRM in HTML5)

While I would normally ignore such blog posts, since this was sent to the
WG and is presented as a "technical review", I feel the need to warn
members that it is riddled with inaccurate statements and comparisons,
misunderstandings of the spec, and assumptions by the author. If you choose
to read it, please do so with a critical eye.

On Sat, Jan 26, 2013 at 8:29 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> I took some time this weekend to do a technical review of the Encrypted
> Media Extensions (EME, aka. DRM in HTML5) specification.
>
>    TL;DR: The Encrypted Media Extensions (DRM in HTML5) specification
>    does not solve the problem the authors are attempting to solve,
>    which is the protection of content from opportunistic or
>    professional piracy. The HTML WG should not publish First Public
>    Working Drafts that do not effectively address the primary goal of
>    a specification.
>
> The blog post can be found here:
>
> http://manu.sporny.org/2013/drm-in-html5/
>
> Full text is below:
>
>    A few days ago, a new proposal was put forward in the HTML Working
>    Group (HTML WG) by Microsoft, Netflix, and Google to implement
>    [1]DRM in HTML5. This triggered an uproar about the [2]morality
>    and ethics behind DRM and building it into the Web. There are good
>    arguments about morality/ethics on both sides of the debate but
>    ultimately, the HTML WG will decide whether or not to pursue the
>    specification based on technical merit. I am a member of the HTML
>    WG. I was also the founder of a start-up that focused on building
>    a legal, peer-to-peer, content distribution network for music and
>    movies. It employed DRM much like the current DRM in HTML5
>    proposal. During the course of 8 years of technical development,
>    we had talks with many of the major record labels. I have
>    first-hand knowledge of the problem, and building a technical
>    solution to address the problem.
>
> The Problem
>
>    The fundamental problem that the Encrypted Media Extensions (EME)
>    specification is attempting to solve is to find a way to reduce
>    piracy (since eliminating piracy on the Web is an impossible
>    problem to solve). This is a noble goal as there are many content
>    creators and publishers that are directly impacted by piracy.
>    These are not faceless corporations, they are people with families
>    that depend on the income from their creations. It is with this
>    thought in mind that I reviewed the specification on a technical
>    basis to determine if it would lead to a reduction in piracy.
>
> Review Notes for Encrypted Media Extensions (EME)
>
> Introduction
>
>    The EME specification does not specify a DRM scheme in the
>    specification, rather it explains the architecture for a DRM
>    plug-in mechanism. This will lead to plug-in proliferation on the
>    Web. Plugins are something that are detrimental to
>    inter-operability because it is inevitable that the DRM plugin
>    vendors will not be able to support all platforms at all times.
>    So, some people will be able to view content, others will not.
>
>    A simple example of the problem is Silverlight by Microsoft. Take
>    a look at the [3]Plugin details for Silverlight, specifically,
>    click on the "System Requirements" tab. Silverlight is Microsoft's
>    creation. Microsoft is a HUGE corporation with very deep pockets.
>    They can and have thrown a great deal of money at solving very
>    hard problems. Even Microsoft does not support their flagship
>    plugin on Internet Explorer 8 on older versions of their operating
>    system and the latest version of Chrome on certain versions of
>    Windows and Mac. If Microsoft can't make their flagship Web plugin
>    work across all major Operating Systems today, what chance does a
>    much smaller DRM plugin company have?
>
>    The purpose of a standard is to increase inter-operability across
>    all platforms. It has been demonstrated that plug-ins, on the
>    whole, harm inter-operability in the long run. The one shining
>    exception is Flash, but we should not mistake an exception for the
>    rule. Also note that Flash is backed by Adobe, a gigantic
>    multi-national corporation with very deep pockets.
>
> 1.1 Goals
>
>    The goals section does not state the actual purpose of the
>    specification. It states meta-purposes like: "Support a range of
>    content security models, including software and hardware-based
>    models" and "Support a wide range of use cases.". While those are
>    goals, the primary goal isn't stated once in the Goals section.
>    The only rational primary goal is to reduce the amount of
>    opportunistic piracy on the Web. Links to [4]piracy data collected
>    [5]over the last decade could help make the case that this is
>    worth doing.
>
> 1.2.1. Content Decryption Module (CDM)
>
>    When we were working on our DRM system, we took almost exactly the
>    same approach that the EME specification does. We had a plug-in
>    system that allowed different DRM modules to be plugged into the
>    system. We assumed that each DRM scheme had a shelf-life of about
>    2-3 months before it was defeated, so our system would rotate the
>    DRM modules every 3 months. We had plans to create genetic
>    algorithms that would encrypt and watermark data into the file
>    stream and mutate the encryption mechanism every couple of months
>    to keep the pirates busy. It was a very complicated system to keep
>    working because one slip up in the DRM module meant that people
>    couldn't view the content they had purchased. We did get the
>    system working in the end, but it was a nightmare to make sure
>    that the DRM modules to decrypt the information were rotated often
>    enough to be effective while ensuring that they worked across all
>    platforms.
>
>    Having first-hand knowledge of how such a system works, it's a
>    pretty terrible idea for the Web because it takes a great deal of
>    competence and coordination to pull something like this off. I
>    would expect the larger Content Protection companies to not have
>    an issue with this. The smaller Content Protection companies,
>    however, will inevitably have issues with ensuring that their DRM
>    modules work across all platforms.
>
> The bulk of the specification
>
>    The bulk of the specification is what you would expect from a
>    system like this, so I won't go into the gory details. There were
>    two major technical concerns I had while reading through the
>    implementation notes.
>
>    The first is that key retrieval is handled by JavaScript code,
>    which means that anybody using a browser could copy the key data.
>    This means that if a key is sent in the clear, the likelihood that
>    the DRM system could be compromised goes up considerably because
>    the person that is pirating the content knows the details
>    necessary to store and decrypt the content.
>
>    If the goal is to reduce opportunistic piracy, all keys should be
>    encrypted so that snooping by the browser doesn't result in the
>    system being compromised. Otherwise, all you would need to do is
>    install a plugin that shares all clear-text keys with something
>    like [6]Mega. Pirates could use those keys to then decrypt
>    byte-streams that do not mutate between downloads. To my
>    knowledge, most DRM'ed media delivery does not encrypt content on
>    a per-download basis. So, the spec needs to make it very clear
>    that opaque keys MUST be used when delivering media keys.
>
>    One of the DRM systems we built, which became the primary way we
>    did things, would actually re-encrypt the byte stream for every
>    download. So even if a key was compromised, you couldn't use the
>    key to decrypt any other downloads. This was massively
>    computationally expensive, but since we were running a
>    peer-to-peer network, the processing was pushed out to the people
>    downloading stuff in the network and not our servers. Sharing of
>    keys was not possible in our DRM system, so we could send the
>    decryption keys in the clear. I doubt many of the Content
>    Protection Networks will take this approach as it would massively
>    spike the cost of delivering content.
>
> 6. Simple Decryption
>
>      The "org.w3.clearkey" Key System indicates a plain-text clear
>      (unencrypted) key will be used to decrypt the source. No
>      additional client-side content protection is required.
>
>    Wow, what a fantastically bad idea.
>
>     1. This sends the decryption key in the clear. This key can be
>        captured by any Web browser plugin. That plugin can then share
>        the decryption key and the byte stream with the world.
>     2. It duplicates the purpose of Transport Layer Security (TLS).
>     3. It doesn't protect anything while adding a very complex way of
>        shipping an encrypted byte stream from a Web server to a Web
>        browser.
>
>    So. Bad. Seriously, there is nothing secure about this mechanism.
>    It should be removed from the specification.
>
> 9.1. Use Cases: "user is not an adversary"
>
>    This is not a technical issue, but I thought it would be important
>    to point it out. This "user is not an adversary" text can be found
>    in the first question about use cases. It insinuates that people
>    that listen to radio and watch movies online are potential
>    adversaries. As a business owner, I think that's a terrible way to
>    frame your customers.
>
>    Thinking of the people that are using the technology that you're
>    specifying as "adversaries" is also largely wrong. 99.999% of
>    people using DRM-based systems to view content are doing it
>    legally. The folks that are pirating content are not sitting down
>    and viewing the DRM stream, they have acquired a non-DRM stream
>    from somewhere else, like Mega or The Pirate Bay, and are watching
>    that. This language is unnecessary and should be removed from the
>    specification.
>
> Conclusion
>
>    There are some fairly large security issues with the text of the
>    current specification. Those can be fixed.
>
>    The real goal of this specification is to create a framework that
>    will reduce content piracy. The specification has not put forward
>    any mechanism that demonstrates that it would achieve this goal.
>
>    Here's the problem with EME - it's easy to defeat. In the very
>    worst case, there exist piracy rigs that allow you to point an HD
>    video camera at a HD television and record the video and audio
>    without any sort of DRM. That's the DRM-free copy that will end up
>    on Mega or the Pirate Bay. In practice, no DRM system has survived
>    for more than a couple of years.
>
>    Content creators, if your content is popular, EME will not protect
>    your content against a content pirate. Content publishers, your
>    popular intellectual property will be no safer wrapped in anything
>    that this specification can provide.
>
>    The proposal does not achieve the goal of the specification, it is
>    not ready for First Public Working Draft publication via the HTML
>    Working Group.
>
> References
>
>    1.
>
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
>    2. http://www.defectivebydesign.org/
>    3.
> http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx
>    4.
>
> http://www.dga.org/Craft/DGAQ/All-Articles/1001-Spring-2010/Internet-Issues-Piracy-Statistics.aspx
>    5.
>
> http://www.musicweek.com/news/read/effects-of-blocking-pirate-bay-short-lived-criticised-as-ineffective/049604
>    6.
>
> http://techcrunch.com/2013/01/19/mega-launches-its-cloud-storage-and-file-sharing-service-as-the-privacy-company-amid-a-huge-surge-of-interest/
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/
>
>