This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
(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.
(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.
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.
*** Bug 20959 has been marked as a duplicate of this bug. ***
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).
Added a note to the abstract calling this out as an open issue. https://dvcs.w3.org/hg/html-media/rev/da30d94614ac
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.
*** Bug 20992 has been marked as a duplicate of this bug. ***
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.
*** Bug 20967 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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
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.
(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.
ACTION-32: Draft wiki page to register CDM key system names (Glenn) https://www.w3.org/html/wg/media/track/actions/32
(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.
That might be better than nothing, but it's still far short of what I'm proposing.
(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.
(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
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.
(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."
(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
(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.
(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.
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. ]]
(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.
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.
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.
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
(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.
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.
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.
(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
Ah, excellent! Thanks for that. So at first glance it looks like Microsoft has satisfied part #2 of comment #0.
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?
(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.
In the past browsers have competed and marketed on "standards compliance".
(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.
(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.) ]]
Correct.
tl;dr: Skip to comment #45. comment #0 starts with the following threat example: "a UA vendor... 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." A variant of that would be "encouraging the creation of content and applications that are consumable only by a specific CDM and the user agent(s) that support it." While other interop issues have been discussed in this bug, I believe this one is the most important for the web platform. If not addressed, siloed content may simply be moved from native apps and plugins to <video> while remaining accessible to only a fraction of user agents and users. Much of the discussion that followed the threat example was about a key system/CDM registry, but, as the original description notes, "These requirements are not the only possible fix..." As I explain below, I do not think such a registry is necessary or addresses the real issues. The proposed uses (in comment #4 and elsewhere) for the information such a registry might contain seem to fall into three primary categories: 1) Understanding the [observable] behavior, etc. to help identify the source of problems, UA integration difficulties, interoperability problems, etc. 1.1) This could also theoretically be used to implement compatible functionality in other key systems. 2) Improve consistency of various implementations of a given key system across UAs. For example, two browsers using the same OS APIs should behave identically. 3) Ability to reimplement a CDM, i.e. if it becomes orphaned. While important, I do not believe these address the primary interoperability concern as they do not ensure that EME applications or content are interoperable across key systems. For example, even if one knows how a CDM operates, other key systems may not be able to replicate it or the content may not contain the necessary information for other key systems (i.e. it relies on information in a proprietary PSSH box). A more direct and perhaps effective solution to #1 would be to document the expected observable behavior of CDMs in the EME spec. That is, how and when keys and licenses are obtained, destroyed, etc. (As with #1, this does not cover robustness mechanisms, etc.) #2 is really interoperability within a given key system. This is important and really applies to all implementations of a key system, not just those using a specific (e.g. OS) API. CDM providers should document how to use their APIs and other underlying implementations in the appropriate locations. For example, if there is an OS API, such documentation should be publicly available; if use of the CDM requires other arrangements, such documentation should be provided as part of those arrangements. It is good to remind CDM providers of this recommendation (and to provide compatibility tests to verify implementations), but I am not sure that a public registry is necessary to accomplish the goals. Providing this information is in the CDM providers' interest as noted in comment #39. I believe #3 becomes less of an issue if we are successful in encouraging interoperable applications, content, license acquisition, etc. (proposed solution to #1). If a content provider supports multiple key systems, the demise of one CDM does not itself make the content inaccessible. Content availability mostly relies on the content provider except in the case of permanent offline licenses. (Solutions for that depend on how the license was issued and may have nothing to do with the CDM implementation.)
As mentioned above, I think it would be more effective and beneficial to the web platform to document the expected observable behavior and capabilities of CDMs rather than the unique behavior of each CDM. Robustness mechanisms/features and keys/secrets may vary, but we should be able to document the observable capabilities. This will benefit application developers (less key system-specific code [1], easier to support new key systems) and users (more content on more clients). This will also make behaviors more explicit and less dependent on proprietary content metadata, such as PSSH boxes. As discussed in bug 17673, such headers are a threat to EME interop. Ideally, custom PSSH boxes should not be necessary for all/most (common) scenarios and a common CENC protection system [2] can be used. The spec currently specifies interoperable solutions for streaming and offline playback. We should continue this model for specifying observable behavior. [1] Ideally, key system selection code is the only part of the application that needs to be key system-specific, as shown in the examples: https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#example-selecting-key-system [2] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-format.html#common-system; bug 24027
(In reply to David Dorwin from comment #45) > As mentioned above, I think it would be more effective and beneficial to the > web platform to document the expected observable behavior and capabilities > of CDMs rather than the unique behavior of each CDM. Robustness > mechanisms/features and keys/secrets may vary, but we should be able to > document the observable capabilities. My proposal here has always been only about documenting observable behavior. Non-observable behavior (such as internal robustness features) is not relevant to "enabling independent implementation" and "enabling content deployment". So, AFAICT we don't disagree :-). Your additional interop concerns are noted and welcome.
(In reply to David Dorwin from comment #45) > This will also make behaviors more explicit and less dependent on > proprietary content metadata, such as PSSH boxes. As discussed in bug 17673, > such headers are a threat to EME interop. Ideally, custom PSSH boxes should > not be necessary for all/most (common) scenarios and a common CENC > protection system [2] can be used. I filed bug 27093 related to proprietary initialization data, such as key system-specific PSSH boxes. (In reply to Robert O'Callahan (Mozilla) from comment #4) > -- 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). Proprietary PSSH boxes may also play a role in such scenarios. If they are encrypted or not documented, it may not be possible to determine the key ID(s) required to decrypt the content.
Moved to EME GitHub issue: https://github.com/w3c/encrypted-media/issues/192 /paulc HME WG Chair