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: Jet Villegas W3C <w3c@junglecode.net>
Date: Fri, 1 Feb 2013 08:57:09 -0800
Message-ID: <CAP82YM6qvjgyDcL4VG-rfebp99OHEPmeUjAaSrRw2VznSmt8cg@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, robert@ocallahan.org, Sam Ruby <rubys@intertwingly.net>, public-html-admin@w3.org
The scenario you describe seems very unlikely given the realities of
DRM-protected content distribution. The only likely service degradation is
"no service" for UA's without the installed CDM's. The distribution of
CDM's is very tightly tied to revenue share %, plug-in bundling deals,
breach response contracts, and other binding agreements between user agent
providers and DRM content distributors. UA's that don't sign such deals and
their users are locked out of the content. I don't see this to be an
improvement to the Flash and Silverlight alternatives in use today, and we
really should do better than that.


On Fri, Feb 1, 2013 at 7:56 AM, Glenn Adams <glenn@skynav.com> wrote:

> On Thu, Jan 31, 2013 at 8:48 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> On Thursday 2013-01-31 16:39 -0700, Glenn Adams wrote:With CDMs, on the
>> other hand, the data communicated between parties
>> is the tuple (encrypted data, key system).  This means the
>> underlying data are meaningless unless both parties know what the
>> key system is.  This, in turn, is why it's important that the key
>> systems or the content decryption modules implementing them be
>> registered.
> From the content authoring perspective as well as actual function of EME,
> the only reason to employ a registry is to prevent name collisions for key
> string identifiers. Since EME defines use of reversed DNS identifiers, then
> this implicitly satisfies that requirement.
> From the perspective of UA implementers, a registry containing additional
> information -- e.g., a full or partial specification of the key system, a
> contact point for obtaining additional information or licensing, etc. --
> would only be needed if a UA wished to directly implement a CDM that
> supported some key system. Alternatively, a UA implementer could provide an
> Add-On/Extension mechanism to permit system administrator or end user
> installation of a CDM implementation supplied by a third party.
> For example, let's say I sign up for a first release HD video service that
> encrypts its media streams. That sign-up service may entail determining if
> my UA supports certain media types and certain key systems. If it does not
> support the required key system, then it may ask me to authorize
> downloading an Add-On/Extension that does support it. If I don't authorize
> it, or if the UA does not support downloading a CDM, then the service
> provider may choose instead to use one of the built-in CDMs supported by
> the UA as determined when querying support for media types and key systems.
> If the service provider doesn't find an acceptable supported CDM, then it
> may offer a lower level service, such as non-HD or non-first release, etc.
> Do you believe this scenario is infeasible given the current design of EME?
Received on Friday, 1 February 2013 16:57:37 UTC

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