W3C home > Mailing lists > Public > public-html-admin@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: Mon, 11 Feb 2013 02:29:24 -0700
Message-ID: <CACQ=j+f2s5O1wwBURgaxyi1CNfST0ZVz8VAnhLHq6JBLR6GYzA@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Mark Watson <watsonm@netflix.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
On Mon, Feb 11, 2013 at 12:10 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Sat, Feb 9, 2013 at 5:27 AM, Mark Watson <watsonm@netflix.com> wrote:
> > We must see what we can do to relax these requirements, but I would not
> > accept that the test should be that specification must fully define a DRM
> > system, as you suggest. We do not do this for other HTML specifications:
> The
> > video element does not define a codec, the geo-location API does not
> define
> > a method of determining geographic location, WebGL can't be implemented
> > (performantly) without hardware which is in practice proprietary (i.e.
> > graphics cards).
>
> The same is not true for EME with the kind of CDMs that actually
> matter. It appears that the proponents of EME intend to target content
> to CDMs that will not be independently interoperably implementable
> without access to secrets.
>

Are you suggesting that the W3C should set or limit business terms for how
content owners or content providers services provide their
content|services, for example, by eliminating the ability for a content
providers to use reasonable technical measures to protect against
unauthorized access to some content?

In other words, are you suggesting that a 3rd party that wished to provide
or enable a given CDM for two browsers UA1 and UA2 should not be able to do
so if they must resort to non-public information of any kind in their CDM
implementation(s)?

If so, then would you place the same restriction on implementations of TLS,
which already supports extensible key and bulk encryption systems [1]?

[1] http://www.rfc-editor.org/rfc/rfc5246.txt
Received on Monday, 11 February 2013 09:30:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 February 2013 09:30:14 GMT