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 following text in the Abstract is not supported by technical requirements in the specification and should be removed. Specifically, whether or not out-of-band communication is or is not permitted is a function of the CDM/UA or CDM/Platform interfaces, neither of which is specified by EME. "This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server."
This makes a lot of sense and it makes EME compatible with other CDMs deployed in the real world. Here is a suggestion how to change the non-normative text: Abstract: 1. Original text: “License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.” Proposed text: “License/key exchange may be controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.” 2. Original text: “The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.” Proposed text: “The common API supports a simple set of content encryption capabilities, allowing application functions such as authentication and authorization to be performed by page authors. This is achieved by enabling content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.”
Agreed. That is a good improvement that better retains existing language.
(In reply to Petr Peterka from comment #1) > This makes a lot of sense and it makes EME compatible with other CDMs > deployed in the real world. This has already been discussed and resolved in bug 17615: "EME is founded on the message exchange pattern. If you do not need to exchange messages then EME doesn't add any value..." - https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615#c5 (In reply to Glenn Adams from comment #0) > The following text in the Abstract is not supported by technical > requirements in the specification and should be removed. Specifically, > whether or not out-of-band communication is or is not permitted is a > function of the CDM/UA or CDM/Platform interfaces, neither of which is > specified by EME. The message exchange pattern is fundamental to the EME design and algorithms. It is also an important aspect of the security and privacy considerations and enabling interoperable web applications to be built on top of EME. *** This bug has been marked as a duplicate of bug 17615 ***
Not accepted. The proposed changes (as amended by Petr) does not contravene the either EME design or algorithms. Further, the current language "rather than assuming" does not actually prevent use of OOB communication. Nor does any other normative requirement in EME [prevent use of OOB communication]. Further still, the behavior of interface between CDM and UA and platform is UA/platform dependent, and undefined by EME. It is up to UA vendors to determine what constraints to impose on those interfaces, and such constraints are outside the scope of EME.
Furthermore, this is not about using EME APIs or an OOB channel. Certain CDMs and certain use cases require both.
There are several reasons why EME should be restricted to having session communication mediated by the application: 1) At least some limited security analysis with respect to the same origin policy is possible 2) Development of cross-platform applications is greatly simplified if there is consistent behavior across CDMs - typically, capabilities exposed by web specifications are entirely consistent in their behaviour across platforms. In this case we unfortunately cannot escape some differences (different platforms may support different CDMs), but we should constrain the CDM behavior as far as we can to be consistent. 3) The model in which a DRM communicates directly with a license server can be implemented by browsers without EME. However, this hasn't happened. EME introduces a new, distinct, model in the hope that this will succeed for the browser space where the old model failed. Finally, the modifications to existing DRM systems required to support the EME interaction model are simple compared to the modifications required to integrate with a browser at all. There does not seem to be a compelling implementation-effort reason to lift the restriction. This aspect of EME has been central to the proposal from the very first discussions at the Web and TV workshop more than two years ago. It would be a significant change in direction to relax it. In fact I would rather that we strengthen this requirement in some normative way.
As discussed in the last call, to clarify the intend of using a side channel while supporting EME: The intent is to allow interoperability in the selection of the CDM and content decryption but allows flexibility in how the license is retrieved: The application may use needkey, isTypeSupported() and CreateSession() and the CDM may use initData, but will not GetLicense via the Application but contact a license server directly. We don’t see a change in the current normative section to support this mode. To Mark's points: 1) Agreed on the importance and the CDM should still respect the same origin policies 2) Also agreed on consistent behavior. The resulting workflow exists already for the case where the license is already present, e.g. persistent or embedded. Also, the application will still select the CDMs it supports and can ignore other choices. 3) Not sure what the old model is. It does not have a basis for interoperability that we want to achieve. If it’s plugins, they are allowing direct communication and are widely used. As a DRM provider we would disagree that the required modifications are simple, since, for example, it has implications on security and IPR. Regarding the initial proposal, the Web & TV Interest Group requirements document for content protection mandates "an interface to allow any content protection system to be used to protect content" – so this should also apply to content protection that is deployed by hundreds of operators today. If this was the basis for defining requirements for EME, I’d argue there should rather be compelling reasons to exclude some content protection system from the EME.
https://dvcs.w3.org/hg/html-media/rev/f8e25bb791fe adds text to eliminate any ambiguity between the normative text and intent (as stated in the Abstract).
The new text [1] is overly vague: 1.17 + <p>Messages related to "one-time" application-independent initialization that are sent to a pre-defined URL MAY be handled by the user agent and not passed to the application via the APIs. 1.18 + The related operations MUST be performed by the user agent, and such messages MUST still be transmitted via the user agent's network stack. 1.19 + </p> Please define the following in a sufficiently precise manner to facilitate testing these assertions: (1) messages (2) one-time application-independent (3) pre-defined URL (4) handled by the user agent (5) related operations (6) performed by the user agent [1] https://dvcs.w3.org/hg/html-media/rev/f8e25bb791fe
Although I do not agree with everything in the draft TAG opinion on EME [1], they do say: "Although CDMs are necessarily underspecified for robustness reasons, this should not be used as a loophole to drive through vendor-specific behavior. Out-of-band communication (via the CDM or otherwise) should not be possible, nor should vendor-specific extensions or extension points be blessed into the spec." Direct CDM <-> license server communication goes directly against this recommendation. [1] https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md
(In reply to niels t from comment #7) > > To Mark's points: ... > 3) Not sure what the old model is. It does not have a basis for > interoperability that we want to achieve. If it’s plugins, > they are allowing direct communication and are widely used. > At any time since the introduction of the HTML Video Element, web browser implementors could have chosen to integrate DRMs without modification of the HTMLVideoElement API, with the DRM having direct network access to communicate with the license server. So far, they have chosen not to, but they could still do this with no reference to EME. The EME effort is specifically aimed at determining what constraints need to be applied to DRMs in order to convince web browsers to integrate them. This model, as originally proposed [1] (3.5 years ago), with all application-related communication mediated by the application, is proving empirically successful. In fact, millions of desktop browsers users are already using it. The direct communication model has manifestly failed for desktop web browsers. [1] http://www.w3.org/2010/11/web-and-tv/slides/netflix.pdf, particularly slides 10 and 12.
(In reply to Mark Watson from comment #10) > Although I do not agree with everything in the draft TAG opinion on EME [1], > they do say: > > "Although CDMs are necessarily underspecified for robustness reasons, this > should not be used as a loophole to drive through vendor-specific behavior. > Out-of-band communication (via the CDM or otherwise) should not be possible, > nor should vendor-specific extensions or extension points be blessed into > the spec." > > Direct CDM <-> license server communication goes directly against this > recommendation. I can accept a scenario where CDM communication is mediated by the UA, but the TAG opinion piece seems to want to prohibit that as well "... or otherwise". The new language in EME seems to offer the possibility of some degree of UA mediated communication. This is something I would like to see preserved, and not legislated away. > [1] https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md
The purpose of the new text is to document the intent, which is consistent with the TAG's spec review. The intent is that all application-specific and origin-specific messages go through the application via the APIs defined in the EME spec. This includes all license exchange messages. The text Glenn quoted in comment #9 is intended to avoid prohibiting the user agent from handling client initialization/individualization and/or forcing all applications to handle it. Only such traffic is allowed to NOT be passed through the application. As noted in the text, these should be rare and not occur for every origin using the key system. (In reply to Glenn Adams from comment #9) > The new text [1] is overly vague: > > 1.17 + <p>Messages related to "one-time" > application-independent initialization that are sent to a pre-defined URL > MAY be handled by the user agent and not passed to the application via the > APIs. > 1.18 + The related operations MUST be performed by the user > agent, and such messages MUST still be transmitted via the user agent's > network stack. > 1.19 + </p> > > Please define the following in a sufficiently precise manner to facilitate > testing these assertions: I disagree that these are not sufficiently precise or more vague than other normative text dealing with the varied nature of key system implementations. I've further explained each below. (For simplicity, I've used "individualization" as a generic term for such initialization.) Suggestions for more precise text is welcome. > (1) messages "Message" is used throughout the spec. Basically, any communication intended to be sent over a network or provided to/from another endpoint (i.e. server). > (2) one-time application-independent "One-time" refers to the rarity of such events. For example, a client generally only needs to be individualized once. As mentioned in the note, this also applies to re-individualization. Application-independent means that the exception does not apply to anything that includes application data, its origin, etc. > (3) pre-defined URL A URL that is pre-determined in the CDM implementation and does not depend on the application, application origin, etc. > (4) handled by the user agent The user agent MAY handle (in response to an indication from the CDM) and/or drive the individualization process without involving the application. The user agent would be responsible for any permissions/prompts and performing the necessary network traffic. > (5) related operations Operations related to what was described in the previous sentence (i.e. individualization). > (6) performed by the user agent Same as #4. #4 introduces the possibility and #5 and #6 constrain it. > > [1] https://dvcs.w3.org/hg/html-media/rev/f8e25bb791fe (In reply to Glenn Adams from comment #12) > (In reply to Mark Watson from comment #10) > > Although I do not agree with everything in the draft TAG opinion on EME [1], > > they do say: > > > > "Although CDMs are necessarily underspecified for robustness reasons, this > > should not be used as a loophole to drive through vendor-specific behavior. > > Out-of-band communication (via the CDM or otherwise) should not be possible, > > nor should vendor-specific extensions or extension points be blessed into > > the spec." > > > > Direct CDM <-> license server communication goes directly against this > > recommendation. > > I can accept a scenario where CDM communication is mediated by the UA, but > the TAG opinion piece seems to want to prohibit that as well "... or > otherwise". The new language in EME seems to offer the possibility of some > degree of UA mediated communication. This is something I would like to see > preserved, and not legislated away. > > > [1] https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md The new text is consistent with the TAG's spec review except for the very narrow exception for individualization. I think there are legitimate reasons* for allowing the user agent to handle this on platforms that require it without jeopardizing interoperability, privacy, or security, especially given the restrictions in the text. We can seek clarity from the TAG on this specific exception. * This includes simpler applications, simpler servers, client/device deployment and innovation without requiring license server updates, and privacy with respect to whether the device has previously been initialized.
Note that the messages and operations in the exception are specific to the client (i.e. device or platform) and independent of and unaffected by the application or its origin. On the other hand, per-origin individualization would go through the application via the EME APIs.
(In reply to David Dorwin from comment #13) > The new text is consistent with the TAG's spec review except for the very > narrow exception for individualization. I think there are legitimate > reasons* for allowing the user agent to handle this on platforms that > require it without jeopardizing interoperability, privacy, or security, > especially given the restrictions in the text. We can seek clarity from the > TAG on this specific exception. > > * This includes simpler applications, simpler servers, client/device > deployment and innovation without requiring license server updates, and > privacy with respect to whether the device has previously been initialized. According to http://lists.w3.org/Archives/Public/www-tag/2014Oct/0080.html, such individualization wasn't the subject of the review text on out-of-band communication. I think the current exception is fine.
I have attempted to clarify the existing text in https://dvcs.w3.org/hg/html-media/rev/6cae6df4babd. If someone has concerns about the initialization/individualization exception or related text, please open a separate bug on that topic.