Re: Technical Review of EME (DRM in HTML5)

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.

> 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 02:27:03 UTC