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

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

>
> I'm not sure how we can do better than EME/CDM at the current time. We
> aren't going to define a universally acceptable, fully PAS defined CP
> system any time soon (if ever), and I highly doubt anyone else is either.
> However, if and when someone does so, then we could add it as a second
> mandatory CDM in a newer version of EME, along side the existing, and
> admittedly inadequate ClearKey CDM.
>
> Or do you have some concrete ideas about how to do this better?
>

There's a concrete idea: a universally acceptable, fully PAS defined CP
system. I don't see anyone outside this group to be capable of building
that, and be able to reach consensus on such a system. I realize that
current CP systems in wide use have significant "black magic" to obfuscate
by entropy, but I don't think it's impossible to create a publicly
available implementation here.


>
> On Fri, Feb 1, 2013 at 9:57 AM, Jet Villegas W3C <w3c@junglecode.net>wrote:
>
>> 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.
>>
>> --Jet
>>
>>
>> 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?
>>>
>>>
>>>
>>
>