Re: Technical Review of EME (DRM in HTML5)

Sent from my iPhone

On Jan 29, 2013, at 7:26 PM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

> On 01/28/2013 10:27 PM, Mark Watson wrote:
>>> 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.
> 
> I know the authors are aware of that.
> 
>> We're also aware that this doesn't constitute any kind of DRM or 
>> content protection scheme.
> 
> That's definitely not what the spec says:
> 
> All user agents must support the simple decryption capabilities
> described in this section [Clear Key] regardless of whether they support
> a more advanced CDM. This
> *ensures that there is a common baseline level of protection*
> that is guaranteed to be supported in all user agents, including those
> that are entirely open source. Thus,
> *content providers that need only basic protection*
> can build simple applications that will work on all platforms
> *without needing to work with any content protection providers*

'Basic protection' and 'baseline level' are the key phrases here. I believe there is a class of content for which this could be sufficient (there are those who argue that no protection at all is sufficient for all content, so there's presumably some middle ground).

The spec does assume that you know what you are doing.

> 
> The spec doesn't say anything about it being helpful for testing purposes

I thought it did. It certainly should.

> 
> The spec calls it a CDM (aka DRM plugin).

No, CDM and 'DRM plugin' are not synonymous.

It's not necessarily the case that CDMs are plugins either. That's up to browser implementations and from what I understand, no one is planning a general plugin framework for this.

One of the cases I am most concerned with is the one where the CDM is part of the underlying platform, for example on a TV.

> 
> The spec doesn't warn against its use in deployment, but rather promotes
> it as a viable protection mechanism.
> 
> The spec requires this protection mechanism.
> 
> Proposed changes:
> 
> 1. Say the Clear Key CDM is for testing purposes and make it not required.
> 2. Don't imply that ClearKey provides protection or should be used in
> any production system.

Ok, so this is simple actionable feedback. Thank you. A caveat emptor on clearkey seems like a good idea to me.

> 3. Specify a CDM that is open source that has an minimum acceptable
> level of protection for content creators.

That would not be much use unless it was also Royalty Free. If we knew how to specify an RF, open-source-friendly CDM that met most content creators requirements then I'm fairly sure we would have done that from the start. (If you know how to do that, then please tell us).

As it is, specifying a uniform interface with a well-defined interaction model is the best I think we can do to get us away from the need for monolithic alternative environments like Silverlight and Flash.

> 
> The people reading your spec don't have the benefit of talking directly
> to you, they have no idea what the authors intent was. Thus the words in
> the spec are the only thing that matters, and the words in the spec
> right now make it clear that Clear Key is basic protection mechanism
> that is ready for production use in simple applications.
> 
>> The draft doesn't claim that it does.
> 
> It does, see above.
> 
>> 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.
> 
> Yes, but then they read the text in the spec that contradicts what is
> obvious to them (paraphrasing):
> 
> [Clear Key] ... ensures that there is a common baseline level of
> protection ... content providers that need only basic protection can
> build simple applications that will work on all platforms
> without needing to work with any content protection providers
> 
>> 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.
> 
> You seem to be taking this personally, so let me clarify my thoughts
> about the authors:
> 
> I have never said I had a low opinion of the authors. I don't know them.
> I assume that they're good people that are trying to do their job. I
> assume that they have pressures from their companies to make this spec
> "work". I realize that, for them, there is a great deal on the line
> here. I wish them absolutely no ill will. In fact, quite the opposite.
> My technical review has absolutely nothing to do with the intellectual
> capacity of the authors.
> 
> I was very careful in the blog post to criticize the specification and
> the ideas presented, not the people behind them. Everything I'm saying
> now is criticizing the specification, not the people behind it.

When you assume that the authors have proposed something 'fantastically bad', such as using a system which exposes the key for all kinds of content, you are implicitly assuming the authors didn't realize it was fantastically bad.  The more likely alternative explanation is that this mechanism was not intended to be used that way in the first place.

I know the blog form tends to the polemic, and it is fun to use superlatives, but your comment would have been better phrased along the lines that the spec needs to be clearer about the obvious limitations of the clearkey scheme.

> 
>> Is it possible that a more likely explanation exists for the 
>> inclusion of clearkey than the fantastic stupidity of the authors ?
> 
> Where do I call the authors stupid? You are putting words in my mouth
> that I don't think I have ever said. If I did say them, I apologize
> profusely, but I'd like to see the link to the text where I make such a
> statement before doing so.

See above.

> 
>> Perhaps some applications that you are not aware of ?
> 
> Perhaps, but unless that application is made known in the specification
> (which I don't think it is), then other people are going to have the
> same issue with the specification.
> 
>> 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.
> 
> Great! Then call it Test Key, make it clear that its intended purpose is
> for testing and then don't require it to be implemented.
> 
>> 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.
> 
> What are those use cases?

Well, for example, suppose I want to share my family videos with my family and I want them encrypted on the cloud
service I use for sharing.

> Why is your use cases document not linked to
> the specification? Did I miss these use cases in the spec somewhere?
> 
> If all you need to do is decrypt data, why aren't you just using a
> JavaScript library or the WebCrypto API to accomplish that?

Sure, WebCrypto + MediaSource would be an alternative - much more complex - approach.

> 
>> There are simpler point solutions to this case, but since we are 
>> proposing a framework it makes sense to include it.
> 
> I don't think it makes sense, not in the way that the specification
> includes it. What you're saying actually does makes more sense than what
> the spec says, so you guys should probably move the spec text toward that.
> 
> -- 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 Wednesday, 30 January 2013 04:02:51 UTC