Re: [Bug 20944] New: EME should do more to encourage/ensure CDM-level interop

On Sat, Mar 2, 2013 at 4:39 AM, Glenn Adams <glenn@skynav.com> wrote:

> On Wed, Feb 27, 2013 at 3:13 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Mon, Feb 18, 2013 at 3:02 PM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>>  Since all of these extension points are not only present, but
>>> officially sanctioned via standardized extension mechanisms, the problem is
>>> not whether there are non-standard extensions, but how to manage the use of
>>> extensions, and how to [eventually] promote to standard widely adopted
>>> extensions.
>>>
>>
>> The problem --- which is unique to EME --- is that promoting common CDMs
>> to proper standardization is off the table. No EME proponent has proposed
>> such a thing. Unlike codecs or image formats, there are no off-the-shelf
>> standard CDMs that we can expect to be used. Even my proposals, which fall
>> well short of full standardization, are resisted.
>>
>
> (1) you are putting the cart before the horse; we won't get "off-the-shelf
> standard CDMs" until EME is published and implementation activity occurs;
> normally in the W3C we draft a spec, go through a few public working
> drafts, have a LC, then a call for implementation phase (CR); you appear to
> be asking for the results of the CR phase to precede the FPWD, which is
> contrary to W3C process (or at least not expected or required);
>

You misconstrue me; I am not saying we need to have standardized CDMs
before we standardize EME. (My proposal doesn't even require any CDM to be
fully standardized!) I am saying creating the EME extension point while
there is no sign the important extensions will become standardized is a
problem we haven't faced before.

(2) you seem to have ignored the fact that at least Netflix and Cox (in my
> role as their representative) have indicated that we would like to see the
> eventual standardization of CDMs.
>

That's good, but of limited usefulness because you are not CDM vendors.

If a known Hollywood-grade CDM vendor, say Microsoft or Google, were to
step up and say they intend to standardize their CDM, that would mean
something.


> EME is unique among extension points because its requirements entail
>> restrictions on interop: a CDM that anyone can reimplement can't provide
>> the protection that CDMs aim to provide.
>>
>
> This is a mis-characterization of EME. EME does not place any such
> restrictions on interop. This is a deployment decision by users, just like
> whether MP4 is used rather than WebM.
>

Henri already said it well in
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0149.html:

It's pretty clear that EME is motivated by the desire to have
something that Hollywood would deem acceptable for streaming their
movies (and possibly come up with something that pleases video
producers with lesser requirements as a side effect).

It's completely unproductive to try to cast doubts upon the motivation
and suggest it's about something else.



>
>>
>> By the logic that I've heard suggested, failing to publish EME without
>>> publishing the ultimately used CDM protocols/interfaces is the same as
>>> failing to publish HTML{Video,Media}Element APIs without choosing specific
>>> video formats and a standardized code integration interface.
>>>
>>
>> I'm not sure what you mean by "code integration interface". The media
>> format analogy of my "binding requirement" proposal would be a requirement
>> that if vendor X has APIs supporting format Y in their platform, and vendor
>> X has a UA that supports format Y, it should be documented how to implement
>> support for format Y using those APIs. But for media formats this is
>> trivial; on every significant platform, it's well documented how to take
>> the bytes of a media resource and play them using the platform's media APIs.
>>
>
> To use EME as a point of departure, by "code integration interface" I mean
> the (unspecified) interface between the UA and the CDM.
>

My proposal does not require documenting that interface (deliberately so).


>
>> Any restriction to content that depends on EME would come at the hands of
>>> the UA vendor (by not supporting some CDM), the content author (by
>>> requiring a specific CDM), or the content supplier/aggregator (by making
>>> choices among available content with CDM dependencies). In none of these
>>> cases is the restriction due to a limitation of EME as a specification.
>>>
>>
>> I've proposed concrete improvements to EME that I believe will make these
>> outcomes less likely. Either I'm wrong and they would have no effect, or
>> the absence of those improvements is a "limitation of EME as a
>> specification" making those outcomes worse.
>>
>
> As I've indicated, I don't object to defining a registry. Do you have
> other concrete suggestions?
>

Yes, they're in the bug.


> As for promoting interoperability, I haven't seen an objective score card
> on the overall interoperability of the W3C's works. If such a score card
> were ever written, I could offer a great deal of evidence of how the W3C
> has reduced interoperability, e.g., by promoting alternative specifications
> with overlapping (or identical) functional goals.
>

I could talk all day long about the W3C's mistakes, but that is totally
irrelevant here.


>
>> Agreed, however:
>>>
>>>    - the existence of a CDM registry entry does not guarantee that an
>>>    implementation of the CDM is available on a given device (any more than
>>>    registry of a video codec format guarantees the video format is supported
>>>    on a device)
>>>    - the absence of a CDM registry entry does not prevent any set of
>>>    CDMs from being implemented and being available on a set of devices
>>>
>>> For example, let's say MrBigContentCompany devises a CP system and
>>> publishes a non-PAS definition of the system available to anyone for free
>>> (both specification and IPR), but only under an NDA that limits disclosure
>>> of an obfuscation technique used by the system. Let's call this system "
>>> 1.obfuscation.cdm.mrbigcontent.com".
>>>
>>
>> It's not published if it's under NDA.
>>
>
> No. "published" != PAS
>

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944#c0 I meant
"published" to mean "in public" i.e. not under NDA.


>
>
>> I should clarify, though, that obfuscation techniques used in the
>> implementation of a CDM would usually not need to be part of the
>> publication for my part 1 requirement --- since, as I understand it, they
>> typically don't affect what "goes over the wire" and hence don't affect
>> interop.
>>
>
> It depends. But one cannot make this assumption (that it isn't necessary
> to know the portion of the specification governed by an NDA which imposes
> some obfuscation/secret).
>

If describing the operation of the CDM on-the-wire, except for secret keys,
makes it easy to break the CDM, that CDM must be very poorly designed.
(Just as any other cryptographic protocol whose security depends on secrecy
of the protocol is anathema these days.) I hope and expect actual CDMs are
better designed than that.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]