W3C home > Mailing lists > Public > www-archive@w3.org > February 2013

Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

From: Glenn Adams <glenn@skynav.com>
Date: Sun, 3 Feb 2013 07:23:09 -0700
Message-ID: <CACQ=j+fJ+qRc7RD_W3W8Q-Y7znNZrWoK+d1-bSVgpGHzZRrNXQ@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, www-archive <www-archive@w3.org>
On Sat, Feb 2, 2013 at 8:40 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 02/02/2013 08:39 PM, Glenn Adams wrote:
>
>> The point being made on public-html is that the current private
>> assurances seem to be at variance with the long time observable public
>> behavior.
>>
>
> Note: I am by no means saying that such objections are blocking.  What I
> am saying is that such objections have been expressed, and we need to
> provide a substantive response to these objections.
>

Just one last point, which is that such objections are not objections to
EME per se, but to the entire domain of content encryption as it has been
fielded in the past. I'm not sure any adequate, substantive response is
possible, since the same objection could be made to any proposal to support
content encryption.

For example, an alternative proposal might be to reframe EME as an
extension to TLS that would allow a pluggable key and encryption method in
TLS as well as a JS API that interacts with TLS that serves the same
functions as being proposed with EME. The only really new aspect of this
would be the JS API, since TLS already supports arbitrary encryption and
key types (as chosen during the initial handshake). It seems to me one
could potentially make the same objections to this reframed proposal as are
currently being made for EME, yes? Which, if so, shows that the objection
is not specifically related to EME as such.

At bottom, the objection seems to be with the past business practices of
content providers (driven by content owner licensing restrictions). The W3C
doesn't seem to have any control over such practice, and it seems unusual
to propose restricting W3C technical solutions due to past business
practices in another solution domain. Even if such business practices
continued, would that be a legitimate reason to block EME, which can
certainly serve uses that don't follow such past practices?

I think this is all I can add to this thread, so let me make this my last
reply, unless you wish me to answer something specific.

Regards,
Glenn
Received on Sunday, 3 February 2013 14:23:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 3 February 2013 14:23:58 GMT