Re: Technical Review of EME (DRM in HTML5)

Sent from my iPhone

On Feb 3, 2013, at 9:36 AM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

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

Yes, and that's just fine. It's up to people with content to protect to decide what meets their needs, not up to us.

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

Does that matter if there are other use-cases as well ?

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

No, I'm just trying to be accurate about which parts of the system we are specifying here and which we are not. I'm not trying to pretend that this isn't about DRM. When I say we're not specifying a DRM system I don't mean to say we're specifying something else entirely, but that we're not specifying the whole thing. In fact we're leaving almost all of the actual DRM part to the CDMs.

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

You seem to be assuming we have something to hide. We're not downplaying anything. I'm just trying to explain what is and is not in scope of the proposal. 

We're defining an API that can be used to interact with CDMs that implement DRM, and yes, that is the primary use-case that concerns me. But we're not defining a complete DRM system or a plugin architecture, as I said.


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

Personally, I think the most likely
way forward is to try and get OS/platform vendors to expose system APIs for these capabilities so that - like many other system capabilities implemented in a closed-source proprietary way - they can be accessed by any and all applications, Open Source or otherwise.

Remember that whilst there are software-only DRM implementations, the widest range of content is available to those implementations with hardware support.

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

As I said, I would expect browsers
To be quite particular about the CDMs they support, including requiring quite detailed information about the CDM so that they can properly asses the privacy risks etc.

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

IANAL and fair use is a legal issue. I think we have to assume that content providers will abide by the law and take whatever measures they are required to by law to enable fair use - if any. I appreciate that some may argue that those requirements (if they exist and here the IANAL really kicks in for me) should be strengthened, but W3C is not the place for that discussion.

...Mark
> 
> -- 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 20:59:10 UTC