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

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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:22 UTC