Bug 20944 - EME should do more to encourage/ensure CDM-level interop
EME should do more to encourage/ensure CDM-level interop
Status: NEW
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
: 20959 20992 (view as bug list)
Depends on:
Blocks: 20963
  Show dependency treegraph
 
Reported: 2013-02-11 05:24 UTC by Robert O'Callahan (Mozilla)
Modified: 2014-01-15 19:10 UTC (History)
17 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert O'Callahan (Mozilla) 2013-02-11 05:24:13 UTC
The current EME draft makes no attempt to encourage interop at the CDM level. For example, the current EME draft does not forbid or even discourage a UA vendor from promulgating a CDM that no other user-agent can support, and encouraging the creation of content for that CDM consumable only by that user-agent. Such an outcome would be antithetical to the mission of the W3C, and the W3C should not bless, appear to bless, or enable such scenarios.

I believe it is possible to fix this bug without making major changes to EME or CDM technology, without discarding existing EME/CDM requirements, and that it's worth making at least a good-faith effort to try. I believe this should be settled (at least to the point of committing to fix the bug) before EME progresses further, or any requirements we need to add to EME and CDMs are likely to be rejected as "too late".

My proposed fix is to have EME require CDMs to be registered in a central registry. To be registered, a CDM would have to meet the following conditions:

1) Documentation must be published describing the complete operation of the CDM, in enough detail to enable independent implementation in user-agents and to enable content deployment by content providers, except for some set of secret keys whose values may be withheld. (Similar to but weaker than IANA's "specification required" registry policy.)

2) If the CDM vendor offers functionality to third parties to decrypt content that can be decrypted by the CDM, then it must publish documentation describing how to implement the CDM using that functionality. (E.g. if a DRM platform vendor implements a CDM using that DRM platform, other consumers of that platform must also be able to implement the same CDM.)

These requirements are not the only possible fix, and may in fact be an inadequate fix, but I believe they're a lot better than nothing.
Comment 1 Robert O'Callahan (Mozilla) 2013-02-11 05:42:09 UTC
Note that my proposal doesn't completely eliminate the threat example in the first paragraph of comment #0. I don't believe that threat can be completely eliminated without severely limiting the strength of CDMs. But my proposal should reduce the threat, and a good-faith effort to maximise CDM interop while retaining the other requirements is worthwhile.
Comment 2 Glenn Adams 2013-02-11 09:15:05 UTC
(In reply to comment #0)
> The current EME draft makes no attempt to encourage interop at the CDM
> level.

This is not a well defined statement in the sense that neither "interop" nor "at the CDM level" are defined concepts.

> For example, the current EME draft does not forbid or even discourage
> a UA vendor from promulgating a CDM that no other user-agent can support,
> and encouraging the creation of content for that CDM consumable only by that
> user-agent.

This statement suggests that the EME draft "encourag[es] the creation of content ... consumable only by that user-agent". However, no reference is made to language in the draft that makes such a suggestion.

Further, by analogy, the HTML5 draft "does not forbid or even discourage a UA vendor from promulgating" a large number of possible UA dependent features, such as UA specific video codecs, UA specific geo-location devices, UA specific input method editors, UA specific fonts, UA specific canvas context implementations, and so forth.

This "bug" report appears to assert that conceptual CDM architecture, which is essentially a UA dependent implementation feature outside the scope of EME, should be proscribed in terms of how a UA vendor chooses to support specific CDM functionality and which functionality is to be supported by that vendor.

This form of mandate would represent an abrupt shift in the independence of UA implementors in terms of which W3C specifications are implemented, as well as how implementation specific decisions are made.

> Such an outcome would be antithetical to the mission of the W3C,
> and the W3C should not bless, appear to bless, or enable such scenarios.

The W3C mission is well defined by its published documents and particularly the W3C Process Document. The development of the EME specification has occurred within the charter of the HTML WG in accordance with the W3C Process (unless the reporter is claiming otherwise).

If the reporter of this "bug" takes issue with that charter and/or process, then the "bug" should be registered against those documents. As such, this "bug" does not represent a technical issue, but is instead a philosophical or business argument about how some UA vendors perceive their own mission and how they pursue their own individual philosophical or business goals.

> I believe it is possible to fix this bug without making major changes to EME
> or CDM technology, without discarding existing EME/CDM requirements, and
> that it's worth making at least a good-faith effort to try. I believe this
> should be settled (at least to the point of committing to fix the bug)
> before EME progresses further, or any requirements we need to add to EME and
> CDMs are likely to be rejected as "too late".
> 
> My proposed fix is to have EME require CDMs to be registered in a central
> registry. To be registered, a CDM would have to meet the following
> conditions:
> 
> 1) Documentation must be published describing the complete operation of the
> CDM, in enough detail to enable independent implementation in user-agents
> and to enable content deployment by content providers, except for some set
> of secret keys whose values may be withheld. (Similar to but weaker than
> IANA's "specification required" registry policy.)
> 
> 2) If the CDM vendor offers functionality to third parties to decrypt
> content that can be decrypted by the CDM, then it must publish documentation
> describing how to implement the CDM using that functionality. (E.g. if a DRM
> platform vendor implements a CDM using that DRM platform, other consumers of
> that platform must also be able to implement the same CDM.)

The reporter does not cite any technical reason why interoperability would be enhanced in the presence of such a registry or reduced in the absence of such a registry. However, given other similar registries, such as the IETF MIME Type registry, it may useful to consider this suggestion for the simple purpose of reducing the likelihood of CDM identification conflict (though one might argue that the current specified use of a reversed domain name already provides adequate identification conflict). If such a registry is introduced, then it should support both a public (standard) and private (pre-standard or non-standard) category of registrations, such as is supported by RFC6838 [1] (cf. Standards tree with Vendor, Personal, and Unregistered trees).

[1] http://www.rfc-editor.org/rfc/rfc6838.txt

If such a registry is created or promoted, then non-standard (vendor, personal, unregistered) portions of the registry should not be subjected to any greater documentation or interoperability requirements than hold for similar registrations (of MIME types) in RFC6838.
Comment 3 Mark Watson 2013-02-12 01:15:55 UTC
(In reply to comment #0)
> The current EME draft makes no attempt to encourage interop at the CDM
> level. For example, the current EME draft does not forbid or even discourage
> a UA vendor from promulgating a CDM that no other user-agent can support,
> and encouraging the creation of content for that CDM consumable only by that
> user-agent. Such an outcome would be antithetical to the mission of the W3C,
> and the W3C should not bless, appear to bless, or enable such scenarios.
> 
> I believe it is possible to fix this bug without making major changes to EME
> or CDM technology, without discarding existing EME/CDM requirements, and
> that it's worth making at least a good-faith effort to try. I believe this
> should be settled (at least to the point of committing to fix the bug)
> before EME progresses further, or any requirements we need to add to EME and
> CDMs are likely to be rejected as "too late".
> 
> My proposed fix is to have EME require CDMs to be registered in a central
> registry. To be registered, a CDM would have to meet the following
> conditions:
> 
> 1) Documentation must be published describing the complete operation of the
> CDM, in enough detail to enable independent implementation in user-agents
> and to enable content deployment by content providers, except for some set
> of secret keys whose values may be withheld. (Similar to but weaker than
> IANA's "specification required" registry policy.)

Hi Robert,

Could you explain a little how you would expect to use such information ? If you created an independent implementation, how would you expect to get the secret keys ? From the original DRM vendor, or by establishing your own key management system ?

Or is the intent just to have concrete information publicly available describing exactly what a given commercial CDM does, for the purpose of security and privacy review ? 

> 
> 2) If the CDM vendor offers functionality to third parties to decrypt
> content that can be decrypted by the CDM, then it must publish documentation
> describing how to implement the CDM using that functionality. (E.g. if a DRM
> platform vendor implements a CDM using that DRM platform, other consumers of
> that platform must also be able to implement the same CDM.)
> 
> These requirements are not the only possible fix, and may in fact be an
> inadequate fix, but I believe they're a lot better than nothing.
Comment 4 Robert O'Callahan (Mozilla) 2013-02-12 08:46:16 UTC
Glenn, I think addressing your comments will not help make progress on this bug, so I'll reply on public-html-media.

(In reply to comment #3)
> Could you explain a little how you would expect to use such information ? If
> you created an independent implementation, how would you expect to get the
> secret keys ? From the original DRM vendor, or by establishing your own key
> management system ?
> 
> Or is the intent just to have concrete information publicly available
> describing exactly what a given commercial CDM does, for the purpose of
> security and privacy review ? 

That is a good question, thanks. I have a few things in mind:

-- I think it will help interoperation if all parties understand what each CDM actually does. Even if a CDM cannot be reimplemented from scratch, its behavior can be understood, bugs can be diagnosed and either worked around or blame assigned to the correct party for a fix.

-- At some point in the future, if a CDM becomes obsolete, unmaintained, or otherwise orphaned, the keys can be either disclosed or if necessary obtained by other means, and then there will be enough information for it to be reimplemented. This is important to ensure interoperation indefinitely far in the future (e.g. for archival purposes).

-- Understanding the operation of the CDMs may expose unexpected interoperability issues that need to be addressed. Right now, since the CDMs are black boxes, third parties don't know "what questions to ask". This information could reveal areas where we need to tighten specifications, or it could reveal actual problems with CDMs that need to be fixed to improve their interoperability across UAs.

-- The transparency around security and privacy that you mentioned, and in general public peer review of systems design, is a valuable effect, although it's not the focus of this bug.
Comment 5 Adrian Bateman [MSFT] 2013-02-12 13:57:31 UTC
*** Bug 20959 has been marked as a duplicate of this bug. ***
Comment 6 Fred Andrews 2013-02-12 20:06:40 UTC
A specific CDM may be issued to users that discriminates against users.

A CDM specific to each user/device may not be a standard at all and may not be able to pass through the W3C review processes.  This bug may be related to Bug 20963 (EME is technically incomplete).
Comment 7 Adrian Bateman [MSFT] 2013-02-13 22:07:44 UTC
Added a note to the abstract calling this out as an open issue.
https://dvcs.w3.org/hg/html-media/rev/da30d94614ac
Comment 8 Zack Martin 2013-02-14 00:30:53 UTC
CDM can be made more interoperable using following design. (I made the same update in Bug 20963 but it is relevant to this bug too.):
- Introduce a requirement that CDMs be downloadable and executable in a sandbox
-- Possible sandboxes might be JVM, .Net, NaCl, etc. Rather than require one 
   particular sandbox, implement a registry of sandbox IDs, and some way to
   request a particular version of that sandbox (e.g. Java version >= 7)
-- Have an XML manifest for the CDM that declares:
---- CDM identity and revision number
---- what sandbox it uses and what revision
---- URL from which it can be downloaded
---- list of native OS services it requires, if any
------ this list may be platform-specific, e.g. Windows API X from Y.dll
       Linux function X from Y.so. Define a naming scheme that works for
       common platforms, e.g. win32:dllname:exportname, linux:dllname:exportname
       make it extensible to support further platforms
------ a sandbox specific API to invoke those native services. This could be
       e.g. P/Invoke under .NET, JNA under Java, etc.
---- UA or sandbox must verify the CDM, either before executing it or while 
     executing it, to ensure it only uses the declared native services. How the
     UA or sandbox should do so would be sandbox-specific.
- Before registering a sandbox, sandbox registry must require:
-- publically available spec or docs for how the sandbox works, sufficient for
   a third-party to reimplement it (I take it this is true for JVM, ISO/ECMA
   CLI, and could easily be made true for NaCL.)
-- Likewise, a spec for the native services invocation API.

With this design, it should be possible for a CDM to work with multiple UAs or
even multiple platforms. Of course, there are no guarantees - the CDM could
always detect the UA or platform and refuse to run - but it means that building
a UA or platform restricted CDM becomes more of a conscious decision and less of
an accident.
Comment 9 Adrian Bateman [MSFT] 2013-02-26 17:13:11 UTC
*** Bug 20992 has been marked as a duplicate of this bug. ***
Comment 10 David Dorwin 2013-02-26 17:47:15 UTC
I changed the Summary back to its original value.
Comment 6 and the associated change to the Summary are a different issue.

Note: The suggestion in Comment 8 was later reported in issue 20992, where more discussion can be found.
Comment 11 Adrian Bateman [MSFT] 2013-05-03 06:29:36 UTC
*** Bug 20967 has been marked as a duplicate of this bug. ***
Comment 12 Andreas Kuckartz 2013-05-03 07:45:37 UTC
As I wrote in issue 20967#15 I think that while these two issues are overlapping they are not duplicates. But I will not care as long as the content of issue 20967 is appropriately dealt with here.

As I also stated in 20967#15 that issue seems to be unfixable (nobody so far has argued that it is fixable). The same therefore is true for this one if these two issues are duplicates. I therefore would _not_ agree with postponing a resolution after publishing the text as FPWD.
Comment 13 Glenn Adams 2013-05-03 16:55:59 UTC
(In reply to comment #12)
> As I wrote in issue 20967#15 I think that while these two issues are
> overlapping they are not duplicates. But I will not care as long as the
> content of issue 20967 is appropriately dealt with here.
> 
> As I also stated in 20967#15 that issue seems to be unfixable (nobody so far
> has argued that it is fixable).

If it is unfixable, then it mostly likely will be resolved as WONTFIX.

> The same therefore is true for this one if
> these two issues are duplicates. I therefore would _not_ agree with
> postponing a resolution after publishing the text as FPWD.
Comment 14 Andreas Kuckartz 2013-06-05 09:37:09 UTC
As a result of the discussion on the mailing list of the W3C Restricted Media Community Group I provide a simple test of formal legal compatibility with Open Source:

Can EME be implemented using the GPLv3 or AGPLv3 license ?

Due to the intended purpose of EME using these licenses also results in certain requirements which have to be satisfied by the CDMs.
Comment 15 Glenn Adams 2013-07-30 16:11:19 UTC
I propose this bug be addressed by:

(1) creating a simple registry off of the HTML WG Wiki that permits volunteer registration of CDMs;

(2) that an informative note be added to 1.2.1 [1] [or some other appropriate location] that recommends registration in this registry and provides a link to it;

(3) that the clear key system described in 6.1 [2] be added to this registry as its first entry, with an informative link added to 6.1 to point at this entry;

I believe these actions should be adequate to close this bug.

[1] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#definitions
[2] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#simple-decryption-clear-key
Comment 16 Robert O'Callahan (Mozilla) 2013-07-30 22:41:11 UTC
That's nowhere near as strong as what I proposed in comment #0; a registry that's merely an incomplete list of CDMs is worthless.
Comment 17 Glenn Adams 2013-07-30 23:27:33 UTC
(In reply to comment #16)
> That's nowhere near as strong as what I proposed in comment #0; a registry
> that's merely an incomplete list of CDMs is worthless.

I expect there will be little agreement in the WG to mandate registration as you propose. A voluntary registration is all that I believe is reasonably possible. Of course, you are free to argue for the stronger case, but I expect there will be insufficient support for that position.
Comment 18 Paul Cotton 2013-08-08 19:11:50 UTC
ACTION-32: Draft wiki page to register CDM key system names (Glenn)
https://www.w3.org/html/wg/media/track/actions/32
Comment 19 Glenn Adams 2013-08-10 00:43:30 UTC
(In reply to comment #16)
> That's nowhere near as strong as what I proposed in comment #0; a registry
> that's merely an incomplete list of CDMs is worthless.

Would you be willing to accept a registry that was divided into two parts:

(1) Open Key Systems

Registration of key systems accompanied by references to public specifications considered to be sufficient to obtain open implementations.

(2) Non-Open Key Systems

Registration of key systems not accompanied by references to public specifications or references to public specifications/information that were deemed inadequate to obtain open implementations, where a labeling as "Non-Open" is not intended to prejudice the deployment or use of such systems.

However, even such a division, if implemented, would require defining some process for determining sufficiency to be labeled Open. This could be as simple as saying that the registrant makes the determination (and claim) either way, which would abrogate the registrar from having to make a determination, and consequently deal with possible dispute and appeal processes.

I very much doubt the W3C would wish to enter into the process of making a determination (for legal reasons), so self-determination might be the only approach.
Comment 20 Robert O'Callahan (Mozilla) 2013-08-10 03:19:42 UTC
That might be better than nothing, but it's still far short of what I'm proposing.
Comment 21 Glenn Adams 2013-08-10 03:55:14 UTC
(In reply to comment #20)
> That might be better than nothing, but it's still far short of what I'm
> proposing.

I will draft a proposed registry along the lines I propose. If you feel the urge and think you can gain sufficient support for your proposal, then you are free to draft an alternative form.
Comment 22 Glenn Adams 2013-08-13 04:54:22 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > That might be better than nothing, but it's still far short of what I'm
> > proposing.
> 
> I will draft a proposed registry along the lines I propose. If you feel the
> urge and think you can gain sufficient support for your proposal, then you
> are free to draft an alternative form.

http://www.w3.org/html/wg/wiki/KeySystemRegistry
Comment 23 Mark Watson 2013-08-13 15:00:32 UTC
I was hoping we would be able to do a little more here, especially for the case of DRMs supported by the operating system.

Specifically, if a DRM is included in the OS, can be accessed through public APIs and can be used to implement EME in a browser then the specification of how to do this should be public. The registry should encourage or require this.

Otherwise we have an obvious interoperability problem where multiple browsers use public OS APIs to implement a CDM, but they do so in different, incompatible, ways.

Potentially, we could go further and say that when a CDM is built using platform APIs then it should be a condition of registration that these APIs are public, rather than secret APIs only available to a single browser.
Comment 24 Glenn Adams 2013-08-13 15:41:48 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > That might be better than nothing, but it's still far short of what I'm
> > > proposing.
> > 
> > I will draft a proposed registry along the lines I propose. If you feel the
> > urge and think you can gain sufficient support for your proposal, then you
> > are free to draft an alternative form.
> 
> http://www.w3.org/html/wg/wiki/KeySystemRegistry

In addition, recommend the following:

Under 1.2.2 Key System add:

"Note: It is recommended that Key Systems by registered at http://www.w3.org/html/wg/wiki/KeySystemRegistry."
Comment 25 Glenn Adams 2013-08-13 16:39:10 UTC
(In reply to comment #24)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > (In reply to comment #20)
> > > > That might be better than nothing, but it's still far short of what I'm
> > > > proposing.
> > > 
> > > I will draft a proposed registry along the lines I propose. If you feel the
> > > urge and think you can gain sufficient support for your proposal, then you
> > > are free to draft an alternative form.
> > 
> > http://www.w3.org/html/wg/wiki/KeySystemRegistry
> 
> In addition, recommend the following:
> 
> Under 1.2.2 Key System add:
> 
> "Note: It is recommended that Key Systems by registered at
> http://www.w3.org/html/wg/wiki/KeySystemRegistry."

During today's telco [1], Adrian asked if "it is recommended" has the force of SHOULD per RFC2119. I failed to note in my response that I propose this "recommendation" to be placed in a Note, which makes it non-normative language. As such, I attempted to avoid use of a normative keyword.

My intention in drafting it as such was that this be a "non-normative recommendation" rather than a "normative recommendation". However, I would not object to it being elevated to the latter.

[1] http://www.w3.org/2013/08/13-html-media-minutes.html
Comment 26 Michael[tm] Smith 2013-08-16 08:40:28 UTC
(In reply to comment #22)
> > I will draft a proposed registry along the lines I propose. If you feel the
> > urge and think you can gain sufficient support for your proposal, then you
> > are free to draft an alternative form.
> 
> http://www.w3.org/html/wg/wiki/KeySystemRegistry

The phrase "a public available specification (PAS) which the registrant believes satisfies some standard of openness" pretty obviously places no real requirement on registrants at all. And "Each entry listed as a Non-Open Key System is encouraged to include a link that references some form of publicly available information about the Key System" does even less.
 
(In reply to comment #23)
> I was hoping we would be able to do a little more here, especially for the
> case of DRMs supported by the operating system.
> 
> Specifically, if a DRM is included in the OS, can be accessed through public
> APIs and can be used to implement EME in a browser then the specification of
> how to do this should be public. The registry should encourage or require
> this.

I agree that the registry could and should require that any DRM system listed in the registry must make available a clear specification about how it can be used to implement EME in a browser. Otherwise, there's really no point in having a registry at all.

> Otherwise we have an obvious interoperability problem where multiple
> browsers use public OS APIs to implement a CDM, but they do so in different,
> incompatible, ways.
> 
> Potentially, we could go further and say that when a CDM is built using
> platform APIs then it should be a condition of registration that these APIs
> are public, rather than secret APIs only available to a single browser.

I agree it should be a requirement of registration that the APIs are public and not only available to a single browser. Because there would otherwise really no point in registering them at all.
Comment 27 Glenn Adams 2013-08-16 17:13:09 UTC
(In reply to comment #26)
> (In reply to comment #22)
> > > I will draft a proposed registry along the lines I propose. If you feel the
> > > urge and think you can gain sufficient support for your proposal, then you
> > > are free to draft an alternative form.
> > 
> > http://www.w3.org/html/wg/wiki/KeySystemRegistry
> 
> The phrase "a public available specification (PAS) which the registrant
> believes satisfies some standard of openness" pretty obviously places no
> real requirement on registrants at all. And "Each entry listed as a Non-Open
> Key System is encouraged to include a link that references some form of
> publicly available information about the Key System" does even less.
>  
> (In reply to comment #23)
> > I was hoping we would be able to do a little more here, especially for the
> > case of DRMs supported by the operating system.
> > 
> > Specifically, if a DRM is included in the OS, can be accessed through public
> > APIs and can be used to implement EME in a browser then the specification of
> > how to do this should be public. The registry should encourage or require
> > this.
> 
> I agree that the registry could and should require that any DRM system
> listed in the registry must make available a clear specification about how
> it can be used to implement EME in a browser. Otherwise, there's really no
> point in having a registry at all.

Registration in this registry is strictly voluntary. The real registry is the DNS, since nothing prevents a User Agent from supporting an arbitrary Key system based on their own DNS entries.

Thus, the purpose of this registry is to permit Key system implementers to declare some level of openness (or not) and to disclose specifications or documentation. That's it, but that's more than nothing.

Finally, you say "implement EME in a browser", but I think you mean Key System, since EME can be implemented by anyone without implementing any Key System except clear key (though such an implementation won't be very useful).

The fact of the matter is that there are a number of Key Systems in use today with protected content that require an NDA to access their specifications. These will not be openly specified any time soon, so any UA vendor will need to work directly with those vendors to determine how to implement support for those Key Systems.

What you propose, of mandating a required open specification, will ensure those systems are not registered, though they will be likely implemented in any case (at least in some UAs) and used by service providers.

If a non-open registry is available for these systems, then it will at least expose their use, which is a small, but non-zero increase in transparency, and will provide an opportunity for those registration entries to disclose some information, even if not sufficient for an open implementation.

Again, this provides a positive benefit, greater than the "there's really no point" you suggest.

> 
> > Otherwise we have an obvious interoperability problem where multiple
> > browsers use public OS APIs to implement a CDM, but they do so in different,
> > incompatible, ways.
> > 
> > Potentially, we could go further and say that when a CDM is built using
> > platform APIs then it should be a condition of registration that these APIs
> > are public, rather than secret APIs only available to a single browser.
> 
> I agree it should be a requirement of registration that the APIs are public
> and not only available to a single browser. Because there would otherwise
> really no point in registering them at all.

I don't agree with this either, since it doesn't interoperability with the status quo. I agree we should encourage use of open APIs if available and used on some platform, and we could add this to the requirements for a registration in the Open Key System registry, but I don't agree that this should be applied to the Non-Open registry.
Comment 28 Michael[tm] Smith 2013-08-16 23:57:31 UTC
For the record here, pasting in comments from roc on the public-html-media list that are relevant.

[[
The proposal in the bug explicitly does not require publication of all the
information required to reimplement a CDM --- since that obviously wouldn't
fly. The proposal in the bug is to publish all information about the
operation of the CDM except for the values of cryptographic keys. This
matches the "best practices" of modern cryptography, in which the security
of a system depends only on keeping secret keys secret, not on keeping
secret how the system works.

Discussion in the bug answers questions recorded in the minutes --- please
read it.

Rather than have group members speculate about the acceptability of these
requirements to CDM vendors, we should elicit direct public feedback from
CDM vendors on whether they can accept these requirements --- and if not,
why not.
]]
Comment 29 Glenn Adams 2013-08-17 00:10:49 UTC
(In reply to comment #28)
> For the record here, pasting in comments from roc on the public-html-media
> list that are relevant.
> 
> [[
> The proposal in the bug explicitly does not require publication of all the
> information required to reimplement a CDM --- since that obviously wouldn't
> fly. The proposal in the bug is to publish all information about the
> operation of the CDM except for the values of cryptographic keys. This
> matches the "best practices" of modern cryptography, in which the security
> of a system depends only on keeping secret keys secret, not on keeping
> secret how the system works.
> 
> Discussion in the bug answers questions recorded in the minutes --- please
> read it.
> 
> Rather than have group members speculate about the acceptability of these
> requirements to CDM vendors, we should elicit direct public feedback from
> CDM vendors on whether they can accept these requirements --- and if not,
> why not.
> ]]

I certainly don't object to (someone) contacting CDM vendors, but whether this is done or not doesn't argue for a different form of registry. Also, since a number of important CDM vendors don't participate here, it is unlikely to produce any useful results. I further doubt that such vendors will disclose their future plans and it is questionable to expect them to do so.

Further, I anyone is suggesting I am speculating about the current requirements from these vendors for obtaining specification material, then I can assure you I am not speculating.

In any case, I have satisfied my action item to create a draft registry proposal. The TF will take it up at this point.
Comment 30 Mark Watson 2013-08-27 15:10:58 UTC
I have added a further requirement to http://www.w3.org/html/wg/wiki/KeySystemRegistry#Registration_Entry_Requirements

"Registrations for keysystems that may be implemented using publicly specified and available APIs to an Operating System or platform-provided CDM capability MUST provide a reference to a publicly available specification(s) detailing the mapping between EME APIs and the relevant platform APIs, sufficient for independent interoperable implementation of the keysystem using those platform APIs."

This closes ACTION-37

I am not sure this is sufficient to close this bug yet, though.
Comment 31 Mark Watson 2013-10-29 17:01:56 UTC
IIUC, there are (at least) three open issues in this long thread:

(1) It was proposed that, as a condition of registration, CDM vendors be required to publish a specification of exactly how their CDM works, except for secret keys that attest to an implementation's robustness.
(2) It was proposed that, as a condition of registration, if a CDM is implemented using an independently distributed component then the APIs for that component must be published, so that everyone using that component can do so in an interoperable way.
(3) It was proposed that, as a condition of registration, if a CDM is implemented using platform APIs then those APIs must be public and publicly available.

We need answers from CDM vendors as to whether these things are acceptable, or not.
Comment 32 David Dorwin 2013-11-14 05:08:15 UTC
I think two separate issues have been raised:
1) CDM implementation details (i.e. to allow independent implementation minus the secret keys).
2) Documentation of APIs (platform or otherwise) that user agents can use to make use of the CDM.

My comments:
1) Does what is being discussed address the real concerns/objections? Would the existence of either of these, especially the first, result in a measurable improvement.
2) If requirements for registering are too onerous, it may end up with no useful entries.
3) The same key system string can be implemented in different ways on different platforms. It's unclear how we would document a key system when there are multiple APIs, implementations, etc. on various platforms. (We'd at least need to figure out how to handle multiple sub entries.)
4) Documentation of internals of any spec implementation seems impractical and could lead to:
 a) Slowed development/deployment/updates/innovation
 b) Stale and useless documentation (even our OSS Clear Key implementation has changed)
 c) A higher barrier to supporting additional platforms
Comment 33 Robert O'Callahan (Mozilla) 2013-11-14 09:07:14 UTC
(In reply to David Dorwin from comment #32)
> I think two separate issues have been raised:
> 1) CDM implementation details (i.e. to allow independent implementation
> minus the secret keys).
> 2) Documentation of APIs (platform or otherwise) that user agents can use to
> make use of the CDM.

These seem unclear and imprecise. Comment #0 is a much more precise statement of what this bug is about.

> My comments:
> 1) Does what is being discussed address the real concerns/objections? Would
> the existence of either of these, especially the first, result in a
> measurable improvement.

Comment #4 addresses that.

> 2) If requirements for registering are too onerous, it may end up with no
> useful entries.

As proposed in comment #0, unregistered CDMs would not be considered conforming. This doesn't prevent people from using unregistered CDMs, but they wouldn't be able to claim compliance with EME.

> 3) The same key system string can be implemented in different ways on
> different platforms. It's unclear how we would document a key system when
> there are multiple APIs, implementations, etc. on various platforms. (We'd
> at least need to figure out how to handle multiple sub entries.)

For part 1 of comment #0, only the observable behavior required for interoperability needs to be documented. Implementation details that vary by platform are presumably not relevant to interoperability.

For part 2 of comment #0, for each platform that offers a DRM component which is utilized by a CDM, documentation for how the CDM's API (via EME) maps to that platform's DRM component would be required. But if the DRM component has the same or similar API across platforms, producing the documentation per platform would be trivial.

> 4) Documentation of internals of any spec implementation seems impractical
> and could lead to:
>  a) Slowed development/deployment/updates/innovation
>  b) Stale and useless documentation (even our OSS Clear Key implementation
> has changed)
>  c) A higher barrier to supporting additional platforms

These sound like generic arguments against specifying or documenting anything anywhere.

Regarding 4a, the proposed requirement is only to document the observable operation of CDMs needed for interoperability. It doesn't constrain the development of CDMs in any way and it doesn't require disclosure of most of the internals of a practical CDM implementation (e.g. the machinery protecting the integrity of the CDM). The only additional cost to CDM developers would be the preparation and release of the necessary documentation. Given the documentation ought to exist internally already, this should not be much work.

Regarding 4b, the document management required is not hard, and the downside of accumulating any obsolete documentation is very small.

Regarding 4c, I don't understand this point at all. In my experience, the better documented a piece of software is, the easier it is to port and maintain. If this is a reference to your point 3, see my response above.
Comment 34 Philippe Le Hegaret 2014-01-14 21:47:28 UTC
I noticed today the following document:
[[
Content Decryption Module Interface Specification

An open interface for enabling HTML5 Encrypted Media Extensions in open source browsers

John C. Simmons

January 2, 2014

Version 1.0
]]
http://download.microsoft.com/download/E/A/4/EA470677-6C3C-4AFE-8A86-A196ADFD0F78/Content%20Decryption%20Module%20Interface%20Specification.pdf

I wonder if such document would be enough to have interop at the CDM level as originally requested here.
Comment 35 Robert O'Callahan (Mozilla) 2014-01-14 22:04:33 UTC
Thanks for the pointer!

That document is a step in the right direction towards addressing part #2 of comment #0 on Microsoft's part. It doesn't completely address part #2 on Microsoft's part, because as I understand it the functionality it documents is not available to all potential consumers of Microsoft's DRM platform; see page 5, "Microsoft will make available to PlayReady licensees a CDMi Implementation designed to work with the PlayReady Device Porting Kit (Device PK)." For example I don't think this helps anyone trying to deploy a browser using PlayReady on Windows 8.
Comment 36 Adrian Bateman [MSFT] 2014-01-14 22:20:50 UTC
(In reply to Robert O'Callahan (Mozilla) from comment #35)
> For example I don't think this helps anyone trying to deploy a
> browser using PlayReady on Windows 8.

That's in this document:
"Supporting Encrypted Media Extensions with Microsoft PlayReady DRM in Web Browsers"
http://msdn.microsoft.com/en-us/library/windows/apps/dn466732
Comment 37 Robert O'Callahan (Mozilla) 2014-01-14 22:29:57 UTC
Ah, excellent! Thanks for that. So at first glance it looks like Microsoft has satisfied part #2 of comment #0.
Comment 38 Silvia Pfeiffer 2014-01-14 22:49:36 UTC
That's great news. I suggest we take this as motivation to actually start a registry as proposed in comment #0 and put a requirement into EME for CDMs to get registered to be regarded as EME compliant?
Comment 39 Adrian Bateman [MSFT] 2014-01-15 02:47:49 UTC
(In reply to Silvia Pfeiffer from comment #38)
> That's great news. I suggest we take this as motivation to actually start a
> registry as proposed in comment #0 and put a requirement into EME for CDMs
> to get registered to be regarded as EME compliant?

Honestly, my opinion of this bug is that EME does NOT need to do more to encourage CDM-level interop. The spec isn't really going to influence whether this happens or not. It's in CDM vendors interest to consider publishing this kind of information.

If someone wants to keep a wiki page of pointers to documentation they are welcome to do that. I don't think creating such a page and making this somehow be a criteria for some kind of recognition of "compliant" is actually going to influence anyone to do anything. If someone's implementation satisfies all the technical requirements of EME and doesn't satisfy this registry piece but yet services start using that implementation what do you achieve?

As an example, I think over time you will see Microsoft continue to consider the best way to make implementations of PlayReady CDMs available. I don't think you can write something into the spec that will materially change those considerations however. I think we'll probably see that from other vendors too.
Comment 40 Robert O'Callahan (Mozilla) 2014-01-15 03:27:21 UTC
In the past browsers have competed and marketed on "standards compliance".
Comment 41 Adrian Bateman [MSFT] 2014-01-15 04:30:24 UTC
(In reply to Robert O'Callahan (Mozilla) from comment #40)
> In the past browsers have competed and marketed on "standards compliance".

Of course they have. But marketing is also well known to gloss over the details and I doubt this detail would carry much weight. Just my personal opinion but my impression is that this is unlikely to make the difference.
Comment 42 Philippe Le Hegaret 2014-01-15 18:17:38 UTC
(In reply to Robert O'Callahan (Mozilla) from comment #37)
> Ah, excellent! Thanks for that. So at first glance it looks like Microsoft
> has satisfied part #2 of comment #0.

Just to make sure I understand. Do you mean that the following part hasn't been satisfied?
[[
1) Documentation must be published describing the complete operation of the CDM, in enough detail to enable independent implementation in user-agents and to enable content deployment by content providers, except for some set of secret keys whose values may be withheld. (Similar to but weaker than IANA's "specification required" registry policy.)
]]
Comment 43 Robert O'Callahan (Mozilla) 2014-01-15 19:10:40 UTC
Correct.