Re: Technical Review of EME (DRM in HTML5)



Sent from my iPhone

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

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

You are looking for division where there really is none.

The terms 'DRM' and 'content protection' are typically used to imply a fairly high level of security. This is how you used them in your post and how I used them in my reply.

That's in no way inconsistent with the idea that the lesser protection offered by clearkey might be of value for some
content. Again, it's the contention of some that _no_ protection is sufficient for _all_ content, and although I don't personally agree with that it's clearly possible that there is some content in the middle ground.

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

There is no secret that the proposal is in large part related to DRM. But it's not about defining a DRM system, it's about defining a uniform API that can be used to interact with both DRM and other decryption components. That's also different from defining a plugin architecture for DRM systems. It's not assumed or required that CDMs will be plugins of any kind.


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

Good, 'cos that pretty much sums it up, IMO.

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

No _particular_ DRM. Two of the authors represent companies with different DRM offerings. For our part the important thing is to have a uniform API. DRM-independent file formats are also important, such as ISO Common Encryption.

Of course there will be implementations involving one DRM or another, but the spec isn't 'driven' by a particular one.

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

I doubt browsers will create plugin mechanisms for CDMs, though of course this is up to them. Having more control over the code which is executing here - for privacy as well as other reasons - is one of the reasons for that.

> 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 think this is up to browsers to determine. If a CDM includes capabilities that enable any given kind of tracking then that CDM should obviously be rendered inoperable by user preference settings that prohibit such tracking.

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

Well, nothing is being added or removed in terms of the services available to the users. We're talking about doing in HTML5 what is already done in Silverlight/Flash etc. No more, no less.

...Mark

> 
>> 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 07:19:45 UTC