Re: Technical Review of EME (DRM in HTML5)

On 01/30/2013 02:19 AM, Mark Watson wrote:
>>> 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.

It seems to me that there are varying opinions on what Clear Key is, the
level of "protection" it provides, and what it can be used for. Perhaps
you and David are on the same page, but it doesn't seem like that from
my point of view.

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

Like what? Who are Clear Key's customers? Does anybody on this mailing
list plan to use Clear Key to protect their artist's content?

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

Again, this is weasel wording around the issue. To use a fairly extreme
analogy, military firearms can be used to hunt wild game, but their
primary purpose is killing people. By focusing on the former, and
downplaying the latter, you embolden people to call you out on the
latter, more dangerous aspects of what you have written about.

The specification doesn't go into any detail about what these other
'decryption components' are.

Spec change suggestion:

1) Detail use cases and examples of other non-DRM decryption components.

> It's not assumed or required that CDMs will be plugins of any kind.

Spec change suggestions:

1) Add a note in the spec strongly advising against CDM plugins that can
be installed via the browser.

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

Great, then put something to that effect in the spec... because, even
though it's logically flawed, it's a much stronger argument than what's
in the spec right now.

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

The response was in relation to his "or any" comment:

"Even if we were to assume that there was any DRM driving this..."

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

How does Mozilla implement this stuff since their entire code base is
open source?

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

How will the browser have any idea that the CDM is engaging in this
activity?

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

I'd argue the no more, no less part. I do see your point that the fair
use implications are similar. I question it because this is a worlds
standards organization that represents the viewpoints of many more
people than just Adobe and Microsoft. This sort of thing (fair use) is
typically discussed when discussing the implications of standards that
this consortium works on.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Sunday, 3 February 2013 17:34:20 UTC