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 application should control which URLs it uses and where it sends data. In general, it seems wrong for the user agent or - especially - the CDM to tell the application where to send a message. URLs present other problems as well: * "An application may choose not to send the message to this URL." * The URLs may be normalized. * URLs can be abused. * URLs may be used incorrectly (i.e. including privacy-sensitive information). * Applications should verify a URL before using it, but there is no way to enforce this and it seems likely many authors will fail to do so. * There are two paragraphs on URLs in the Security Considerations section. With the removal of support for parsing URLs from the initData (bug 25920), the remaining known use cases are a "heartbeat" URL and maybe initialization. These could be handled by the CDM telling the application the type of message it has provided and allowing the application to select, if it wishes, a different server. This is equivalent to the "heartbeat" scenario where the application author would configure the license server to provide a different URL to receive heartbeat messages, but it avoids the issues described above. Thus, I propose changing MediaKeyMessageEvent's definition to (enum types TBD) enum MessageType { "default", "heartbeat",... }; interface MediaKeyMessageEvent : Event { readonly attribute ArrayBuffer message; readonly attribute MessageType type; };
This is much less onerous than removing the URL entirely. But I still have some concerns. In the future we may wish to support "federated content" where a single player can playback content from multiple content publishers. Today that can be done with some DRM schemes by providing that information in the PSSH box. I can see a couple of ways of doing within this scheme but I am not sure whether they will work for everyone. 1) The most obvious way is to include the URL inside the message being sent and then have a single front-end key server decode the message and forward it to the appropriate backend server. This removes the complexity from the client entirely. Is this the scheme you are hoping for? 2) Another way to do this was suggested by Mark on another thread/bug. In that proposal the CDM would encode the information along with the regular key request message in a way that the client application can pull out and consume. This would allow the application to control this process and reduce the server-side processing at the expense of some client side complexity. Some content providers may go this route to avoid the cost of another server. Are there other ways I am not seeing that might be better? If (1) is the way folks really think is best, I think an a section should be added that specifically explains this philosophy to try to head off folks going down path (2). Maybe title it "Network Communications Guidelines"?
The generalized requirement is to allow the CDM to provide 'routing hints' with the message. I don't think constraining the hint to a message type is sufficient. We should be clear that the application is still responsible for sending the request to a valid server, but the choice of server may depend on information from the CDM. CDMs have an open free-form channel to applications in the form of the keymessage. Restricting this 'routing hint' channel will only push people to work around that restriction. It's arbitrary and ineffective. I can think of at least ways that an application could ensure it connects only to valid servers, even if the routing hint from the CDM is not authenticated: - the application may have a list of valid servers from which it can choose, based on the hint - the application may have access to a trusted service which maps hints to valid server URLs I can also think of various ways in which the routing hint from the CDM could be authenticated: - it could itself be a signed object, such as a JWS, which the application can validate using WebCrypto - it could be a known property of the keysystem that it exposes only authenticated hints - it could be assumed that if all information provided to the CDM is authenticated then the information emerging from it is too (for example if the only information passed in was passed in by the application directly over the Media Source Extension). I don't think we should bless or require any particular approach, but we could include some of these in our security considerations.
Shall we just rename this to "Replace MediaKeyMessageEvent's "destinationURL" attribute" ?
The "federation" scenario appears to be the main motivation for a "free-form" value (i.e. comment #1 and comment #2). The assumption/implication is that the license server is encoded in the PSSH. However, this is irrelevant to this bug because URL extraction from initData is not and should not be permitted (bug 25920). Federation is still possible, but it requires metadata such as a manifest, which is increasingly likely with the popularity of DASH and MSE. I believe such URL extraction is the only use case discussed in the related bugs for which an indication of the type of message/server (the proposal in comment #0) is not sufficient. In the absence of concrete alternate proposals for normative interoperable solutions, we should fix the current problem (destinationURL) and get some implementation feedback and experience on the message type solution.
(In reply to David Dorwin from comment #4) > The "federation" scenario appears to be the main motivation for a > "free-form" value (i.e. comment #1 and comment #2). The > assumption/implication is that the license server is encoded in the PSSH. > > However, this is irrelevant to this bug because URL extraction from initData > is not and should not be permitted (bug 25920). FWIW, that was not my understanding of what was agreed with that bug: I thought we had agreed not to specify that destinationURL must be set to the defaultURL extracted from the initData. That's a very different thing from prohibiting the CDM from setting the destinationURL. Anyway, I think we should just agree that we had different understandings of that one and leave it behind us, rather then referring to one understanding as a precedent. > Federation is still > possible, but it requires metadata such as a manifest, which is increasingly > likely with the popularity of DASH and MSE. > > I believe such URL extraction is the only use case discussed in the related > bugs for which an indication of the type of message/server (the proposal in > comment #0) is not sufficient. In the absence of concrete alternate > proposals for normative interoperable solutions, we should fix the current > problem (destinationURL) and get some implementation feedback and experience > on the message type solution. My concrete alternate proposal is: - rename destination URL to 'destination', defined as 'key-system specific message routing information' - include security considerations addressing the necessity for applications to pay proper consideration to the authenticity of indications received over the EME API (I'm happy to draft detailed text) However, if I am the only one arguing for this alternative, I'll agree to the type thing.
(In reply to David Dorwin from comment #4) > The "federation" scenario appears to be the main motivation for a > "free-form" value (i.e. comment #1 and comment #2). The > assumption/implication is that the license server is encoded in the PSSH. > > However, this is irrelevant to this bug because URL extraction from initData > is not and should not be permitted (bug 25920). Federation is still > possible, but it requires metadata such as a manifest, which is increasingly > likely with the popularity of DASH and MSE. I want to clarify something that seems to be confusing many people. The "URL extraction" that bug 25920 was originally referring to and that you seem to be objecting to, is the browser extraction of URL from the initData. I am in agreement that that is problematic because of the proprietary nature of initData. However CDM extraction of URLs from the initData does not have this problem. And since the same initData may be found in the manifest as in the PSSH, the problem does not goes away. > > I believe such URL extraction is the only use case discussed in the related > bugs for which an indication of the type of message/server (the proposal in > comment #0) is not sufficient. In the absence of concrete alternate > proposals for normative interoperable solutions, we should fix the current > problem (destinationURL) and get some implementation feedback and experience > on the message type solution. I don't believe there is an absence of a concrete proposal for interoperability. I believe that the proposal is -- if a URL is provided by the CDM, the application _can_ use it with appropriate validation. We should wait on implementation experience to provide further guidelines here. (In reply to Mark Watson from comment #5) > (In reply to David Dorwin from comment #4) > > The "federation" scenario appears to be the main motivation for a > > "free-form" value (i.e. comment #1 and comment #2). The > > assumption/implication is that the license server is encoded in the PSSH. > > > > However, this is irrelevant to this bug because URL extraction from initData > > is not and should not be permitted (bug 25920). > > FWIW, that was not my understanding of what was agreed with that bug: I > thought we had agreed not to specify that destinationURL must be set to the > defaultURL extracted from the initData. That's a very different thing from > prohibiting the CDM from setting the destinationURL. Agreed. > > I believe such URL extraction is the only use case discussed in the related > > bugs for which an indication of the type of message/server (the proposal in > > comment #0) is not sufficient. In the absence of concrete alternate > > proposals for normative interoperable solutions, we should fix the current > > problem (destinationURL) and get some implementation feedback and experience > > on the message type solution. > > My concrete alternate proposal is: > - rename destination URL to 'destination', defined as 'key-system specific > message routing information' > - include security considerations addressing the necessity for applications > to pay proper consideration to the authenticity of indications received over > the EME API (I'm happy to draft detailed text) I would agree with this proposal, pending reviewing the text.
(In reply to Joe Steele from comment #6) > (In reply to David Dorwin from comment #4) > > The "federation" scenario appears to be the main motivation for a > > "free-form" value (i.e. comment #1 and comment #2). The > > assumption/implication is that the license server is encoded in the PSSH. > > > > However, this is irrelevant to this bug because URL extraction from initData > > is not and should not be permitted (bug 25920). Federation is still > > possible, but it requires metadata such as a manifest, which is increasingly > > likely with the popularity of DASH and MSE. > > I want to clarify something that seems to be confusing many people. The "URL > extraction" that bug 25920 was originally referring to and that you seem to > be objecting to, is the browser extraction of URL from the initData. I am in > agreement that that is problematic because of the proprietary nature of > initData. However CDM extraction of URLs from the initData does not have > this problem. And since the same initData may be found in the manifest as in > the PSSH, the problem does not goes away. That is an inaccurate representation of bug 25920. There has never been any browser extraction of the URL (or anything else) from |initData|. That was never the topic of that bug. The step removed from generateRequest() was the *CDM* extracting a URL from the |initData| and providing it in the event generated within the same algorithm. In theory, nothing currently prevents the CDM from extracting the URL in generateRequest() and using it later to generate a message in a different algorithm. However, that is not intended to be allowed, and it presents the exact same problems (discussed in bug 25920; see also bug 26838) as the removed step. The proposal in comment #0 closes any potential holes. > > I believe such URL extraction is the only use case discussed in the related > > bugs for which an indication of the type of message/server (the proposal in > > comment #0) is not sufficient. In the absence of concrete alternate > > proposals for normative interoperable solutions, we should fix the current > > problem (destinationURL) and get some implementation feedback and experience > > on the message type solution. > > I don't believe there is an absence of a concrete proposal for > interoperability. I believe that the proposal is -- if a URL is provided by > the CDM, the application _can_ use it with appropriate validation. We should > wait on implementation experience to provide further guidelines here. We don't need implementation experience to know that the spec has a security and architectural problem. The longer it persists, the more difficult it will be for authors and implementations to adapt in the future. > (In reply to Mark Watson from comment #5) > > (In reply to David Dorwin from comment #4) > > > I believe such URL extraction is the only use case discussed in the related > > > bugs for which an indication of the type of message/server (the proposal in > > > comment #0) is not sufficient. In the absence of concrete alternate > > > proposals for normative interoperable solutions, we should fix the current > > > problem (destinationURL) and get some implementation feedback and experience > > > on the message type solution. > > > > My concrete alternate proposal is: This solution is neither normative nor interoperable. > > - rename destination URL to 'destination', defined as 'key-system specific > > message routing information' We should not be adding more "key-system specific" mechanisms. The proposal in comment #0 is key system-independent and fully interoperable. > > - include security considerations addressing the necessity for applications > > to pay proper consideration to the authenticity of indications received over > > the EME API (I'm happy to draft detailed text) The user agent, not the application, is responsible for protecting the client and (to the extent that it can) user. The spec should be secure by design, not potentially secure if the application does some optional key system-specific validation.
https://dvcs.w3.org/hg/html-media/rev/18f364378718 implements the proposal in comment #0 with the following types: "licenserequest", "licenserenewal", "licenserelease". We can add more types to the enum if necessary (file a bug). The example in 8.4 is updated to show the optional usage of the type attribute to select a URL for a specific message type.