W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 28 Feb 2012 08:34:27 -0800
Message-ID: <CAAWBYDC67CqY83Zvf6+T_AXGhX1TW8ttvNzgU8CUuPQbmAHPug@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Kornel Lesiński <kornel@geekhood.net>, "<public-html@w3.org>" <public-html@w3.org>
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.

In your other case (server is untrusted), DRM is unnecessary baggage;
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.

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 see no reason why
video is privileged such that it will always maintain this as an
important case, given the history elsewhere.

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.


Received on Tuesday, 28 February 2012 16:35:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC