Re: Technical Review of EME (DRM in HTML5)

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*.

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

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

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.
3. Specify a CDM that is open source that has an minimum acceptable
level of protection for content creators.

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.

> 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.

> 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? 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?

> 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 03:26:24 UTC