Re: Technical Review of EME (DRM in HTML5)

Manu,

I want to respond to one paragraph below, which might explain why you got thee response you did to your post...

Sent from my iPhone

On Jan 28, 2013, at 6:28 PM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

> On 01/27/2013 01:53 PM, David Dorwin wrote:
>> Very well said, Glenn.
> 
> What Glenn said doesn't address any of my concerns:
> 
> http://lists.w3.org/Archives/Public/public-html/2013Jan/0211.html
> 
>> Manu, I had started writing a detailed reply, but there were just so 
>> many issues that I chose a simple reply of caution.
> 
> Can you send the first part of your detailed reply? Perhaps just the
> rough outline of your response? I'd like to know which issues you had
> with the technical review I did.
> 
>> I welcome technical input and suggestions, but there are few 
>> suggestions for improving the specification among the theme that 
>> content protection is impossible so we shouldn't bother. Such a 
>> discussion or personal opposition are fine, but they should not be 
>> presented as a technical review of a specification.
> 
> I never said that you shouldn't bother. I said that the spec doesn't
> seem to technically achieve what I think content publishers want it to
> achieve. However, I don't really even have a clear idea of what the
> specification is trying to achieve. What's the problem that is being
> solved? That's not very clearly laid out in the spec.
> 
> My technical review asks a number of technical questions based on
> analyzing whether the spec text achieves the goals of the specification.
> Namely:
> 
> 1. What exactly is the end-goal of the EME specification? To reduce piracy?
> 
> 2. How does it deal with CDM complexity management over the long-term?
> DRM systems are broken, then replaced, after a while the browser has a
> great deal of cruft built up in supporting old, outdated DRM systems.
> Who deals with this management? When are CDMs purged from the browser
> source? These questions are important because they directly impact
> browser complexity.
> 
> 3. How are CDMs installed and managed? By the browser? By the user? The
> specification seems to imply both.
> 
> 4. Simple Decryption as spec'd seems to provide a broken protection
> mechanism for content, yet it is required for all UAs to implement. Why?
> 
> There are other concerns I have as well, that I didn't mention in the
> blog post like:
> 
> 1. How does accessibility fit into all of this? The word accessibility
> isn't mentioned in the spec once.
> 2. What DRM system is driving the work on this specification?
> 3. What sorts of chips/platforms does this system need to inter-operate
> with?
> 4. Does increasing the attack surface on a browser via completely closed
> DRM plug-in modules pose any privacy risks? How do you know that the DRM
> module isn't tracking everything you're doing online if people can't
> verify the source.
> 5. How does fair-use fit into all of this?
> 6. Who is doing implementations of the spec?
> 
> Answers to each of these questions affect the technical decisions made
> in the specification. You can paint them as non-technical comments if
> you would like, but that doesn't lessen their importance.
> 
>> Constructive technical input from a colleague generally doesn't 
>> include hyperbole and statements like "Wow, what a fantastically bad 
>> idea." and "So. Bad."
> 
> I think the Simple Decryption mechanism in the specification is really,
> really, really bad. I have provided technical reasons. I don't know how
> else to communicate how bad I think it is. It's awful.

The authors are aware that the clearkey scheme results in the key being in the clear within the JS environment. The clue is in the name. We're also aware that this doesn't constitute any kind of DRM or content protection scheme. The draft doesn't claim that it does. To do so would be, as you put it, a 'fantastically bad idea'. This is obvious to anyone who thinks about the problem for a microsecond or so. The fact that you have such a low and preconceived opinion of the authors doesn't encourage people to spend time answering the rest of your comments.

Is it possible that a more likely explanation exists for the inclusion of clearkey than the fantastic stupidity of the authors ? Perhaps some applications that you are not aware of ?

In fact, clearkey has already proved useful for development and testing, including interop testing, as it allows all of the API and the keysystem-independent parts of the system to be exercised without a 'real' DRM.

There are also usecases where the content needs to be protected in storage and transit, but not on the client. TLS doesn't solve this. There are simpler point solutions to this case, but since we are proposing a framework it makes sense to include it.

...Mark

> 
>> It appears you had formed an opinion before even reading the 
>> specification: 
>> https://plus.google.com/102122664946994504971/posts/4aHTBBfxRfW 
>> ("This is awful..." followed by "I haven't read through the spec 
>> yet...")
> 
> At that point in time, I had skimmed through the spec and didn't want to
> give the people in the conversation the impression that I had a full
> understanding of the specification. I sat down over the weekend and read
> through it multiple times. I stand behind what I said and what I
> continue to say about the EME specification.
> 
>> If you are truly interested in improving the specification and would 
>> like to start another thread focused on technical feedback 
>> (preferably on public-html-media where most technical discussion is 
>> occurring), I'd be happy to discuss your concerns.
> 
> My blog post and the submission to this mailing list is technical
> feedback. Feel free to continue the technical discussion in this thread.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Aaron Swartz, PaySwarm, and Academic Journals
> http://manu.sporny.org/2013/payswarm-journals/
> 
>

Received on Tuesday, 29 January 2013 03:27:44 UTC