Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

Sent from my iPhone

On Feb 28, 2012, at 8:34 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> 2012/2/27 Mark Watson <watsonm@netflix.com>:
>> On Feb 27, 2012, at 7:54 PM, Kornel Lesiński wrote:
>>> On Tue, 28 Feb 2012 01:55:18 -0000, Mark Watson <watsonm@netflix.com> wrote:
>>>> There are also use cases where the content provider, for whatever reasons,
>>>> is confident that authorized users will not pass the key or content to
>>>> unauthorized users and in these cases too the "clearkey" system has value.
>>> 
>>> Sorry, I don't see logic in this.
>>> 
>>> If user is trusted not to share the content, how can there be value in
>>> ineffectively trying to protect content from being shared?
>> 
>> There are authorized and unauthorized users. The content should not be
>> shared with the unauthorized ones and this can be done by encrypting it -
>> both in storage and transport.
>> 
>> But there could be cases where the authorized users are trusted not to share
>> the content or the keys. For example, if the video is a family video and the
>> authorized users are members of my family, I may trust them not to share the
>> content outside the family just because I ask them not to. Or the authorized
>> users may all be employees of a company and recognize the importance to the
>> company of not sharing the content outside the company.
>> 
>> I'm sure there are other examples. I was just arguing that clearkey has some
>> utility compared to Henri's proposal to just use https in these cases.
> 
> But it *doesn't* have utility compared to https in this specific case
> - if both the server and the user are trusted, you only need to
> encrypt the connection, and that's what https does.

The server is not necessarily trusted. As I said, https services from CDNs (where they also sell you trustworthiness) are more expensive than http ones.

So I want the content encrypted in storage as well as transport.

> 
> In your other case (server is untrusted), DRM is unnecessary baggage;

Right, we're talkin here about the clearkey keysystem, which is not DRM. One of the reasons we don't call the proposal DRM - it is more general than that.

> you only need JS encryption/decryption that can be inserted between
> the server and a <video> element of the user.  This can be specified
> and implemented without many of the concerns that people have been
> raising about this proposal.

Ok, so now we are on the same page regarding the utility of encrypting the content both for storage and transport, instead of using https. Good.

There are various discussions we could have about the merits of doing the decryption in Jvascript vs in the UA - I believe doing crypto in JS is viewed dimly by the security crowd. By all means argue for a simple-encryption-based solution but please accept that the technical realization (in JS vs in the UA) would deserve discussion.

But really what you are saying is that if this use-case is the only one that needs to be supported then some of the issues raised with the proposal would go away. Well, yes, of course. But this is not the only use-case.

> 
> The only case where the additional machinery of DRM has any value is
> when the user is not trusted.  This case, however, has proven to
> dissolve away in other media industries.  While it's not yet
> completely gone, it's clearly on its way out.

I don't see that from where I'm standing. Fully one third of peak US Internet traffic is DRM-protected video (according to Sandvine), and that's just one company.

>  I see no reason why
> video is privileged such that it will always maintain this as an
> important case, given the history elsewhere.

Maybe - but many companies would like to use HTML5 for these services in the next few years, rather than waiting for you to be proved right.

> 
> Thus, this is a problem that will solve itself.  When the user is
> trusted, you can use either http (when everyone is trusted), https
> (when only the server is trusted), or JS encryption (when no one else
> is trusted).  The case where the user is untrusted will disappear on
> its own, following history in similar media formats, or at least
> become small enough that traditional measures such as legal contracts
> will suffice.
> 

It's not me that you need to convince. I'm actually pretty agnostic on most of what you say above.

I'm just trying to make it easy for
customers to watch TV shows and movies online, legally, on as many devices and in as convenient a way as possible. It's often argued that this is where other content industries went wrong: by not doing this. HTML can help with that.

> ~TJ
> 
> ~TJ
>

Received on Tuesday, 28 February 2012 17:05:07 UTC