RE: Technical Review of EME (DRM in HTML5)

My replies are inline. I have cut out those items to which I am not responding, in the interest of space and clarity.

NB: I've built a PlayReady implementation, and have participated in DRM technical calls with a variety of content producers and publishers, so I have what I think of as a solid understanding of the issues underlying content protection generally and DRM specifically.

This post represents my personal opinions, and not those of my employer.
________________________________________
From: Manu Sporny [msporny@digitalbazaar.com]
Sent: Monday, January 28, 2013 9:26 PM
Subject: Re: Technical Review of EME (DRM in HTML5)

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.

[David Mays] It's important to understand that there is a very broad spectrum of what "content publishers want" in terms of content protection. For some, a simple CDM implementation like clear key decryption is sufficient, because they aren't delivering very high value content, and key protection isn't necessary. Some broadcast content is deliverable using a much lower bar for content protection than is required for a Hollywood feature film. Some content providers find simple, unauthenticated key delivery for HLS to be acceptable. Some like the security offered by Adobe's RTMPe. Others won't settle for anything less than a fully robust PlayReady implementation, with CGMS-A and HDCP enforcement, and peculiar playback window rules. The point is, those matters are out of scope for the W3C. This proposal is about providing an API that *could* be used for *some* use cases where encrypted delivery is a requirement. It is explicitly not about creating a DRM, as some have repeatedly and erroneously claimed.


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?

[David Mays] What is unclear about the Goals section in 1.1? Also, see my remarks above.

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?

[David Mays] See above, RE different levels of content protection for different kinds of content.

1. How does accessibility fit into all of this? The word accessibility
isn't mentioned in the spec once.

[David Mays] What specific accessibility concerns do you have? I think of accessibility as more of an application-layer concern. I don't see anything in this API specification that would prevent the construction of an accessible application.

2. What DRM system is driving the work on this specification?

[David Mays] Even if we were to assume that there was a particular (or any) DRM driving this, why would it matter which one?

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.

[David Mays] I don't think it creates any more privacy concerns than the ones that already exist in today's proprietary closed plug-in world. If you accept Flash or Silverlight into your browser in order to play DRM-protected content, you accept code that you cannot verify. As a practical matter, that is not a relevant issue for the vast majority of people using the web anyway. Typical users are in the "trust, but never verify" category when it comes to privacy. It appears that their desire to consume content outweighs their concerns with respect to privacy, closed-source or DRM.

5. How does fair-use fit into all of this?

[David Mays] It isn't the responsibility of a content publisher to provide the means to produce copies of content for fair use. Even still, as you've pointed out already, as long as photons are painted on a screen, and people have cameras, it is easy to reproduce content. Nothing in fair use doctrine says that a high-quality original digital copy must be made available to a person who wants to exercise their rights under that doctrine. So I think that fair use fits in the same way it does with any other content delivery system.

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.

[David Mays] Again, that isn't productive or constructive feedback. Further, how can you call it "bad" or "awful" when, as you have already stated, you don't know what problem the proposal attempts to solve? Properly evaluating the technical merits of a solution without understanding the intended problem statement seems impossible.

Received on Tuesday, 29 January 2013 03:31:49 UTC