Re: Technical Review of EME (DRM in HTML5)

+CC: Tracking Protection WG (search for 'privacy')

On 01/28/2013 10:31 PM, Mays, David wrote:
> 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.

Yep, understood.

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

This contradicts what Mark Watson, one of the editors of the spec, has
stated, which is:

"[Clear Key] doesn't constitute any kind of DRM or content protection
scheme."

http://lists.w3.org/Archives/Public/public-html/2013Jan/0220.html

"[Clear Key] decryption is sufficient, because high value content isn't
being delivered"?

More importantly, who is going to be using Clear Key in production?

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

Yep.

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

This whole specification is about creating a DRM system. I think the
spec spends a great deal of time weasel wording around the concept of
'protection' vs. just coming out and saying that it's a DRM plugin
architecture.

While the proposal states that it is not defining a DRM plugin system,
that is by far the primary purpose of the specification. While DRM isn't
explicitly required, that is what is going to use the EME specification.
I haven't seen a single non-DRM use case for EME that can't be done with
the Web stack we have today (or will before EME gets to REC).

The bottom line is that the proposal is about DRM. I make no value
judgement on that. I've built DRM systems. I know that you can't often
get content from content companies without them. However, to pretend
that the spec is about 'protection' and not 'DRM' comes across as very
disingenuous (criticizing the spec, not the authors).

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

If the goals section was built around this theme, it would be less bad:
"The Web Platform needs to provide a DRM solution for content companies
who believe that DRM is going to help their bottom line and customers
that are willing to subject themselves to that DRM. The Web Platform is
competing against walled gardens like Flash, Silverlight, and native
players. If we don't do this, then content companies will use the more
error-prone-stack of proprietary plugins such as Flash or Silverlight to
accomplish their goals. This is the lesser of two evils." ... then I'd
be a bit more okay with the spec. However, it doesn't do this and
supporters of the specification keep repeating that this isn't about DRM
when it clearly is about DRM.

It would be even better if a goal was to provide a decent open source
CDM so that companies like Mozilla don't get screwed over by the
royalties from content protection companies.

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

That doesn't address my concern, see:

http://lists.w3.org/Archives/Public/public-html/2013Jan/0220.html

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

Here is a short list of 30 concerns regarding accessibility and DRM'ed
video:

http://joeclark.org/access/resources/DRM.html#implications

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

Are you seriously arguing that there is no DRM solution that is driving
this specification? All of a sudden Netflix, Microsoft, and Google
decide to put editors on the EME specification. Comcast comes out in
support of it as well, and there is no DRM driving the EME proposal? Or
are you saying that the companies involved are implementing the
specification without actually doing integration testing with a DRM system?

As for why would it be helpful to know:

It helps to understand who is going to support this specification in the
long run, the complete systems that will be built using this spec, and
the track record of the companies implementing the DRM system, to name a
few. It helps us understand if there are going to be 3 CDMs, or 25.

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

If there are only ever 2 CDMs and they're by Adobe and Microsoft, then
there are probably no more privacy concerns. However, if there are now
25 different CDMs, and CDMs can be installed via the regular plugin
install process in a browser, there are a very large number of privacy
concerns, not to mention an explosion in the attack surface of a browser
that cannot be audited.

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

Except when something like this happens:

http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal

or this:

http://www.geek.com/articles/games/ubisoft-uplay-drm-found-to-include-a-rootkit-20120730/

How does the spec ensure that it works with the Tracking Preference
Expression specifications?

I don't see anything about the privacy implications that the EME
specification raises. The HTML Media WG should work with the TPWG to
make sure all privacy matters are dealt with by folks that seem to care
more about privacy than you seem to.

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

Not really, EME seems to stomp all over the fair-use activity of
time-shifting a broadcast. So, how does EME protect the fair-use
activity of time-shifting a broadcast? You can kick the can down the
road to CDM creators, but that will inevitably lead to 1) the CDM being
more aggressively attacked to regain the fair-use provision, or 2) a
potential for a class-action lawsuit against a CDM provider due to the
fair-use activity being removed.

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

I outline exactly why this is a bad idea here (and, productively and
constructively, suggest what to do about it):

http://lists.w3.org/Archives/Public/public-html/2013Jan/0220.html

-- 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:34:22 UTC