(In reply to David Dorwin from comment #0)
> The default URL steps in the createSession() algorithm allow a license
> server URL to be extracted from the Initialization Data.
> 
> However:
> * This is inconsistent with EME's application-driven model.

I disagree with this. This is yet another way for information to be provided to the application by the content publisher. 

> * There is only one format that supports this, and it does so using
> proprietary header boxes.

This may or may not be true ( I know of at least one format that supports this) but proprietary header boxes are the nature of CENC. Either we have that or we do not support CENC.

> * Uses of it are unlikely to be interoperable.

This seems to be opinion rather than fact-based. Give me some evidence. 

> * There are no current implementations or applications using it.

This is not true. The Adobe Access implementation of EME uses this. And there is a large amount of existing content using it that will be enabled once EME is more widely deployed. 

> * There is a privacy and security risk in allowing media data to direct an
> application to ping/contact a random server.

I disagree. The contact here will be controlled via origin policy same as any other web content loaded by the page. Please elaborate the risk you see.

> 
> Therefore, we should remove these steps.

I could not disagree more strongly.

(In reply to Joe Steele from comment #1)
> (In reply to David Dorwin from comment #0)
> > The default URL steps in the createSession() algorithm allow a license
> > server URL to be extracted from the Initialization Data.
> > 
> > However:
> > * This is inconsistent with EME's application-driven model.
> 
> I disagree with this. This is yet another way for information to be provided
> to the application by the content publisher. 

Providing instructions to applications via media resources seems like an anti-pattern for the web platform.

> > * There is only one format that supports this, and it does so using
> > proprietary header boxes.
> 
> This may or may not be true ( I know of at least one format that supports
> this) but proprietary header boxes are the nature of CENC. Either we have
> that or we do not support CENC.

CENC *allows* proprietary header boxes and other things that support many use cases, some of which may not make sense for the interoperable web platform.

The same box used for proprietary headers can also be used for open common headers like [1].

There's no reason to throw out a standardized file format just because not every possible usage is supported. For example, MSE and its Byte Stream Format Registry place restrictions on the contents and parsing of BMFF and other formats in order to enable consistent behavior and algorithms across implementations and media types.

> > * Uses of it are unlikely to be interoperable.
> 
> This seems to be opinion rather than fact-based. Give me some evidence. 

Not all key systems support this functionality, and it's not required by the CENC spec. Thus, applications relying on the default URL would need a different path for other key systems. This would also have the effect of making default URL path unnecessary.

> > * There are no current implementations or applications using it.
> 
> This is not true. The Adobe Access implementation of EME uses this. And
> there is a large amount of existing content using it that will be enabled
> once EME is more widely deployed. 

Such content will need corresponding EME-enabled applications, and there is no [public] evidence that default URL support is necessary to use that content.

Unless that content is intended to only be used with the Adobe Access CDM (a non-goal), it will likely need to be repackaged with additional PSSH boxes (at least the common format) and the applications will need to support the other path I mentioned above, making the presence of a URL in the existing content irrelevant.

> > * There is a privacy and security risk in allowing media data to direct an
> > application to ping/contact a random server.
> 
> I disagree. The contact here will be controlled via origin policy same as
> any other web content loaded by the page. Please elaborate the risk you see.

Origin policies protect the target server, not the application or user. Thus, they do not address the risks of an application sending a request to a host specified in a media resource.

One possible attack:
1) A malicious media resource could either be hosted by a server belonging to the application or an unrelated server. In the latter case, since CORS relies on the target server, a malicious server would just allow all Origin values.
2) If the media data is CORS same origin (either via cross-origin XHR or the crossorigin attribute), the needkey event will include the initData.
3) The application responds to the needkey event by passing the initData to createSession().
4) Without the proposed change, the CDM processes the malicious initData, extracts the default URL and provides it in the message event.
5) If the application supports the default URL model, it sends the request to the malicious URL. Again, the malicious server accepts all Origin values.

I don't think we can keep the default URL steps in the spec as is.

> > 
> > Therefore, we should remove these steps.
> 
> I could not disagree more strongly.

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-format.html#common-system

(In reply to David Dorwin from comment #2)
> (In reply to Joe Steele from comment #1)
> > (In reply to David Dorwin from comment #0)
> > > The default URL steps in the createSession() algorithm allow a license
> > > server URL to be extracted from the Initialization Data.
> > > 
> > > However:
> > > * This is inconsistent with EME's application-driven model.
> > 
> > I disagree with this. This is yet another way for information to be provided
> > to the application by the content publisher. 
> 
> Providing instructions to applications via media resources seems like an
> anti-pattern for the web platform.

I don't know what you mean here. Are you saying that the initData (which is coming from the media resources) should not be provided to the application? This seems to be a complete reversal from the initial design. Given that we are providing it and it can contain this information, we should continue to support it. Removing this feature would force CDMs that require it to include this information in the message and force the web application to extract it and handle it directly. That seems like more work than simply checking if it was provided by the CDM and if not figuring it out directly. I am not clear on how you are improving things in general. 

> 
> > > * There is only one format that supports this, and it does so using
> > > proprietary header boxes.
> > 
> > This may or may not be true ( I know of at least one format that supports
> > this) but proprietary header boxes are the nature of CENC. Either we have
> > that or we do not support CENC.
> 
> CENC *allows* proprietary header boxes and other things that support many
> use cases, some of which may not make sense for the interoperable web
> platform.
> 
> The same box used for proprietary headers can also be used for open common
> headers like [1].
> 
> There's no reason to throw out a standardized file format just because not
> every possible usage is supported. For example, MSE and its Byte Stream
> Format Registry place restrictions on the contents and parsing of BMFF and
> other formats in order to enable consistent behavior and algorithms across
> implementations and media types.

I would argue that this feature is a strength of the CENC spec and a way to improve interop, by limiting the proprietary code to the CDM rather than forcing it back into the web application. 

> 
> > > * Uses of it are unlikely to be interoperable.
> > 
> > This seems to be opinion rather than fact-based. Give me some evidence. 
> 
> Not all key systems support this functionality, and it's not required by the
> CENC spec. Thus, applications relying on the default URL would need a
> different path for other key systems. 

This is true. Applications will have to check whether a default URL is provided and if not, provide their own. If you are correct and that is the more common case, then this basically amounts to a single extra decision. As opposed to supporting default URL without this field which would introduce a lot of CDM specific code into the web application.

> This would also have the effect of making default URL path unnecessary.

No -- it would only make it difficult for applications targeting CDMs that require it.

> 
> > > * There are no current implementations or applications using it.
> > 
> > This is not true. The Adobe Access implementation of EME uses this. And
> > there is a large amount of existing content using it that will be enabled
> > once EME is more widely deployed. 
> 
> Such content will need corresponding EME-enabled applications, and there is
> no [public] evidence that default URL support is necessary to use that
> content.

Are you saying that there have to be public implementations of this before you will accept input from the implementors? 

> 
> Unless that content is intended to only be used with the Adobe Access CDM (a
> non-goal), it will likely need to be repackaged with additional PSSH boxes
> (at least the common format) and the applications will need to support the
> other path I mentioned above, making the presence of a URL in the existing
> content irrelevant.

I am not sure what you are referring to when you say the "common format". This assumes that every browser will support a CDM capable of handling this "common format". Unless that "common format" is required (like the ClearKey) this is not guaranteed. And the ClearKey format is not suitable for delivering most keys. If a browser only supports CDMs which require a default URL - this is a real problem.

> 
> > > * There is a privacy and security risk in allowing media data to direct an
> > > application to ping/contact a random server.
> > 
> > I disagree. The contact here will be controlled via origin policy same as
> > any other web content loaded by the page. Please elaborate the risk you see.
> 
> Origin policies protect the target server, not the application or user.
> Thus, they do not address the risks of an application sending a request to a
> host specified in a media resource.
> 
> One possible attack:
> 1) A malicious media resource could either be hosted by a server belonging
> to the application or an unrelated server. In the latter case, since CORS
> relies on the target server, a malicious server would just allow all Origin
> values.
> 2) If the media data is CORS same origin (either via cross-origin XHR or the
> crossorigin attribute), the needkey event will include the initData.
> 3) The application responds to the needkey event by passing the initData to
> createSession().
> 4) Without the proposed change, the CDM processes the malicious initData,
> extracts the default URL and provides it in the message event.
> 5) If the application supports the default URL model, it sends the request
> to the malicious URL. Again, the malicious server accepts all Origin values.
> 
> I don't think we can keep the default URL steps in the spec as is.

Ok -- now I understand the issue you are raising. This seems like a concern. Let me spend some time thinking about this. I would prefer not to throw the baby out with the bath water.

> 
> > > 
> > > Therefore, we should remove these steps.
> > 
> > I could not disagree more strongly.
> 
> [1]
> https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/cenc-
> format.html#common-system

(In reply to Joe Steele from comment #3)
> (In reply to David Dorwin from comment #2)
> > (In reply to Joe Steele from comment #1)
> > One possible attack:
> > 1) A malicious media resource could either be hosted by a server belonging
> > to the application or an unrelated server. In the latter case, since CORS
> > relies on the target server, a malicious server would just allow all Origin
> > values.
> > 2) If the media data is CORS same origin (either via cross-origin XHR or the
> > crossorigin attribute), the needkey event will include the initData.
> > 3) The application responds to the needkey event by passing the initData to
> > createSession().
> > 4) Without the proposed change, the CDM processes the malicious initData,
> > extracts the default URL and provides it in the message event.
> > 5) If the application supports the default URL model, it sends the request
> > to the malicious URL. Again, the malicious server accepts all Origin values.
> > 
> > I don't think we can keep the default URL steps in the spec as is.
> 
> Ok -- now I understand the issue you are raising. This seems like a concern.
> Let me spend some time thinking about this. I would prefer not to throw the
> baby out with the bath water.

I think the risk here is minimal and can be mitigated against. 

This attack requires tricking the application into loading a compromised resource, either because one of their servers was compromised or because the files were compromised during download. If the compromised file is either the manifest or the application itself, there is no additional exposure. The attacker could just leak a random nonce. If the attacker was able to modify a media file on the application providers content delivery server then it gets more interesting. 

Assuming the attacker can generate valid metadata for this key system, and the application does not do additional validation of the URL prior to sending, then the attacker gets a license request. The actual media file and the domain were known ahead of time. Cookies and auth tokens from the application will not be included by the UA. So the only interesting information is whatever the CDM adds to the license request.

Section 7.1.3 deals with the kind of information that might be available to an attacker in this case. I believe a CDM that is complying with the suggestions for increasing privacy here will reduce the effective information leakage here to a single unique identifier tied to that domain.

The obvious mitigation here is that if the application does know which license servers might be sent to, it could validate that this URL is in that list. That would block this attack completely. 

A less obvious mitigation is that creation of valid metadata may not be possible without some type of licensing. This could impose cost and legal constraints and could further enable identification of bad actors.

(In reply to Joe Steele from comment #4)
> (In reply to Joe Steele from comment #3)
> > (In reply to David Dorwin from comment #2)
> > > (In reply to Joe Steele from comment #1)
> > > One possible attack:
> > > 1) A malicious media resource could either be hosted by a server belonging
> > > to the application or an unrelated server. In the latter case, since CORS
> > > relies on the target server, a malicious server would just allow all Origin
> > > values.
> > > 2) If the media data is CORS same origin (either via cross-origin XHR or the
> > > crossorigin attribute), the needkey event will include the initData.
> > > 3) The application responds to the needkey event by passing the initData to
> > > createSession().
> > > 4) Without the proposed change, the CDM processes the malicious initData,
> > > extracts the default URL and provides it in the message event.
> > > 5) If the application supports the default URL model, it sends the request
> > > to the malicious URL. Again, the malicious server accepts all Origin values.
> > > 
> > > I don't think we can keep the default URL steps in the spec as is.
> > 
> > Ok -- now I understand the issue you are raising. This seems like a concern.
> > Let me spend some time thinking about this. I would prefer not to throw the
> > baby out with the bath water.
> 
> I think the risk here is minimal and can be mitigated against. 
> 
> This attack requires tricking the application into loading a compromised
> resource, either because one of their servers was compromised or because the
> files were compromised during download. If the compromised file is either
> the manifest or the application itself, there is no additional exposure. The
> attacker could just leak a random nonce. If the attacker was able to modify
> a media file on the application providers content delivery server then it
> gets more interesting. 
> 
> Assuming the attacker can generate valid metadata for this key system, and
> the application does not do additional validation of the URL prior to
> sending, then the attacker gets a license request. The actual media file and
> the domain were known ahead of time. Cookies and auth tokens from the
> application will not be included by the UA. So the only interesting
> information is whatever the CDM adds to the license request.
> 
> Section 7.1.3 deals with the kind of information that might be available to
> an attacker in this case. I believe a CDM that is complying with the
> suggestions for increasing privacy here will reduce the effective
> information leakage here to a single unique identifier tied to that domain.
> 
> The obvious mitigation here is that if the application does know which
> license servers might be sent to, it could validate that this URL is in that
> list. That would block this attack completely. 

In case it is not clear, I would recommend adding text describing this mitigation to the spc rather than removing this feature. The text would be added to the createSession() procedure between 7.8 and 7.9 and say something like:
"The application MUST validate that the URL contained in default URL refers to an expected server."


> 
> A less obvious mitigation is that creation of valid metadata may not be
> possible without some type of licensing. This could impose cost and legal
> constraints and could further enable identification of bad actors.

We believe default URL is helpful and used today, and should be supported in EME.  It allows default URLs to be extracted from the pssh, which was a design feature of that init data.  It anticipates services that pull content from multiple sources with different license services.  It may be the case that other formats don't support this now, but there should be a path for them to do so if the use case warrants.

We should not assume that applications will do the right thing for security. Instead, we should prevent the insecure operation, especially when there are alternatives and only a fraction of use cases are affected.

See https://w3c.github.io/webappsec/specs/mixedcontent/#categories for descriptions of various types of content and how susceptible they are to attacks. It's also an example of how user agents are enforcing security rather than assuming applications will do the right thing.

Note that XHR - the likely use of the default URL - is in the Blockable Passive Content category because "developers very often use them to gather data that affects program control flow."

The scenario in comment #2 is even worse if the default URL is [used as] a base URL to retrieve resources other than a license. For example, if "license.example.com" is used as the base for things including JavaScript, that represents a much bigger security problem. (A hypothetical use case might be a system where the default URL is used to fetch branding, metadata, etc. for a generic player.)

Note also that "Passive content is optionally blockable when the risk of allowing its usage in a mixed context is outweighed by the risk of breaking significant portions of the web." As there are no existing web platform-based websites relying on a default URL, there is no risk of breaking significant portions of the web and the spec can take a secure approach from the beginning.

Allowing some user agents to provide the default URL in the destinationURL attribute of the MediaKeyMessageEvent would force every application using destinationURL (i.e. for a heartbeat URL provided in the license) to take steps to mitigate the potential risks of the default URL when handling the “message” event.

(In reply to Jerry Smith from comment #6)
> We believe default URL is helpful and used today, and should be supported in
> EME.  It allows default URLs to be extracted from the pssh, which was a
> design feature of that init data.  It anticipates services that pull content
> from multiple sources with different license services.  It may be the case
> that other formats don't support this now, but there should be a path for
> them to do so if the use case warrants.

EME is different from the world in which CENC^ was designed. With EME, the application is in control and there is no need to rely on meta data in the media stream to tell the DRM engine which server to contact.

How likely is such a default URL to be needed in a world of application control and [DASH] manifests? Obtaining the URL from a manifest seems like a better solution than extracting it from proprietary media data. For applications where such a manifest is not present, could they parse the PSSH in JS to extract the URL?

Both alternatives make the application responsible for obtaining the URL, which will hopefully result in more security scrutiny by the authors. At a minimum, this avoids complicating usage of EME for everyone else and presenting this questionable behavior as part of the spec.

^ Note: Default URL isn’t even defined by CENC; it’s just one potential type of data in the proprietary Data section of the PSSH box.

Note: The "destinationURL" attribute would NOT be removed. It would still be set in the Queue a "message" Event algorithm (i.e. based on data in the license), just not from URLs in the initialization data.

Summarizing my comments from the telecon and other conversations:

For other platforms, providing URLs in PSSH boxes allowed a license server URL to be provided to the media/DRM engine, which was responsible for acquiring the license. This is not necessary in EME where the application acquires the license, and most applications will know the license server URL a priori. Also, it seems that standalone media files will be less common as the industry moves to adaptive streaming and manifests (i.e. MSE and DASH).

Extracting instructions for an application from random media files on the Internet is inconsistent with good web practices and definitely not something UAs should do. As currently specified, the user agent/CDM is presenting the application with "instructions", which some applications are likely to follow, that were likely extracted from untrusted media data from unknown sources. Although applications can be implemented in a way that such data is trusted, the spec and UA cannot assume this. The spec currently defines unsafe-by-default behavior, and I think it's inappropriate to leave it that way.

Note that "content federation" - the scenario where default URL might be most useful with EME - is one in which the content streams are more likely to be untrusted (vs. a standalone content provider).

https://dvcs.w3.org/hg/html-media/rev/36adb8dc581a removes the steps and adds related text to the Security Considerations section.

As per comment #9, the change should not have removed the possibility for the CDM to populate the destinationURL field.

(In reply to Mark Watson from comment #11)
> As per comment #9, the change should not have removed the possibility for
> the CDM to populate the destinationURL field.

I don't think comment #9 says this.

Are there scenarios *not related to initData* that would use destinationURL in generateRequest()? If so, we should evaluate how they fit in an interoperable application before adding complexity to support them.

(In reply to David Dorwin from comment #12)
> (In reply to Mark Watson from comment #11)
> > As per comment #9, the change should not have removed the possibility for
> > the CDM to populate the destinationURL field.
> 
> I don't think comment #9 says this.
> 
> Are there scenarios *not related to initData* that would use destinationURL
> in generateRequest()? 

I think the initData scenario alone is compelling. However another scenario that has been discussed is the bootstrapping request. If a CDM requires an initial message exchange before beginning to use licenses on a particular origin, a set of URLs might be hard-coded into the CDM for that purpose. Since the application may only know the set of URLs that can be used and not the one that is actually used, the CDM has to have a way of conveying that information. 

> If so, we should evaluate how they fit in an
> interoperable application before adding complexity to support them.

I don't see how this change would add complexity. Since both the UA and the application have to support this for key request messages in general, making createSession a special case seems more complex not less.

(In reply to David Dorwin from comment #12)
> (In reply to Mark Watson from comment #11)
> > As per comment #9, the change should not have removed the possibility for
> > the CDM to populate the destinationURL field.
> 
> I don't think comment #9 says this.

Well, that's what I understood during the discussion of this bug and would certainly have objected at the time if the proposal was to remove the possibility for the CDN to set the destinationURL. Apologies if that was my min-understanding.

> 
> Are there scenarios *not related to initData* that would use destinationURL
> in generateRequest()? If so, we should evaluate how they fit in an
> interoperable application before adding complexity to support them.

The initialization exchange is one. In this case the application may just need a one-bit indication from the CDM as to whether the message is to be sent to the initialization server or the regular application server. The destinationURL can be used for that (this is what I mean about the destinationURL containing information used for routing - it may not be the actual URL, but it can be something which selects from amongst a set of URLs known to the application).

(In reply to Mark Watson from comment #14)
> (In reply to David Dorwin from comment #12)
> > (In reply to Mark Watson from comment #11)
> > > As per comment #9, the change should not have removed the possibility for
> > > the CDM to populate the destinationURL field.
> > 
> > I don't think comment #9 says this.
> 
> Well, that's what I understood during the discussion of this bug and would
> certainly have objected at the time if the proposal was to remove the
> possibility for the CDN to set the destinationURL. Apologies if that was my
> min-understanding.

Ah, you were saying that comment #9 did not describe the removal so it should have been restored. I interpreted it as saying that comment says we should restore it. Thanks for clarifying.

> > Are there scenarios *not related to initData* that would use destinationURL
> > in generateRequest()? If so, we should evaluate how they fit in an
> > interoperable application before adding complexity to support them.
> 
> The initialization exchange is one. In this case the application may just
> need a one-bit indication from the CDM as to whether the message is to be
> sent to the initialization server or the regular application server. The
> destinationURL can be used for that (this is what I mean about the
> destinationURL containing information used for routing - it may not be the
> actual URL, but it can be something which selects from amongst a set of URLs
> known to the application).

It is unclear to me why the CDM should select a different server to perform initialization then ask the application to do the initialization. Initialization could a) be handled by the user agent with a central server, in which case it would not go through the EME APIs, or b) be handled in a per-application way via the EME APIs. In the latter case, why can't the initialization go through the same server (even if it is then handed off to another server).

It seems wrong that the CDM should be able to tell the application to use a server that is not its own. The assumption for the other uses of destinationURL is that the URL comes from the license. In that case, the license server (likely controlled and configured by the application author) can specify a different URL for certain messages (i.e. heartbeat). With default URL removed, maybe a better solution would be to replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute, which would allow the application to select the appropriate server from its list of servers. This would work for normal messages, heartbeat, and initialization.

(In reply to David Dorwin from comment #15)
> (In reply to Mark Watson from comment #14)
> > (In reply to David Dorwin from comment #12)
> > > (In reply to Mark Watson from comment #11)
> > > > As per comment #9, the change should not have removed the possibility for
> > > > the CDM to populate the destinationURL field.
> > > 
> > > I don't think comment #9 says this.
> > 
> > Well, that's what I understood during the discussion of this bug and would
> > certainly have objected at the time if the proposal was to remove the
> > possibility for the CDN to set the destinationURL. Apologies if that was my
> > min-understanding.
> 
> Ah, you were saying that comment #9 did not describe the removal so it
> should have been restored. I interpreted it as saying that comment says we
> should restore it. Thanks for clarifying.
> 
> > > Are there scenarios *not related to initData* that would use destinationURL
> > > in generateRequest()? If so, we should evaluate how they fit in an
> > > interoperable application before adding complexity to support them.
> > 
> > The initialization exchange is one. In this case the application may just
> > need a one-bit indication from the CDM as to whether the message is to be
> > sent to the initialization server or the regular application server. The
> > destinationURL can be used for that (this is what I mean about the
> > destinationURL containing information used for routing - it may not be the
> > actual URL, but it can be something which selects from amongst a set of URLs
> > known to the application).
> 
> It is unclear to me why the CDM should select a different server to perform
> initialization then ask the application to do the initialization.
> Initialization could a) be handled by the user agent with a central server,
> in which case it would not go through the EME APIs, or b) be handled in a
> per-application way via the EME APIs. In the latter case, why can't the
> initialization go through the same server (even if it is then handed off to
> another server).

The point here is that we had a stable design (CDM sets destinationURL in keymessage event) which several people had determined was sufficient for their use-cases, even if those use-cases were not spelled out in the discussions.

We did not agree to change this aspect of the design. We agreed to remove the requirement that destinationURL be set equal to the defaultURL from the initData. The change associated with this bug did more than was agreed.

So, we should first - as a matter of procedure - revert the part of the change which was not agreed and *then* get to discussion of further changes people would like.

> 
> It seems wrong that the CDM should be able to tell the application to use a
> server that is not its own. The assumption for the other uses of
> destinationURL is that the URL comes from the license. In that case, the
> license server (likely controlled and configured by the application author)
> can specify a different URL for certain messages (i.e. heartbeat). With
> default URL removed, maybe a better solution would be to replace
> MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute,
> which would allow the application to select the appropriate server from its
> list of servers. This would work for normal messages, heartbeat, and
> initialization.

Personally I have no strong opinion about what the field is called so long as it is a free-form string or ArrayBuffer, rather than an integer. I've a preference for it to be called something which implies the intended usage is to influence the routing of the keymessage.

(In reply to Mark Watson from comment #16)
> (In reply to David Dorwin from comment #15)
> The point here is that we had a stable design (CDM sets destinationURL in
> keymessage event) which several people had determined was sufficient for
> their use-cases, even if those use-cases were not spelled out in the
> discussions.

The spec is subject to change and improvement:
"Implementers should be aware that this specification is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions."

There are no guarantees in this phase that incompatible changes won't be made, especially if they improve security, privacy, and interoperability or address architectural issues. Scenarios that have not been disclosed or adequately described to the group are especially likely to be impacted. 

> We did not agree to change this aspect of the design. We agreed to remove
> the requirement that destinationURL be set equal to the defaultURL from the
> initData. The change associated with this bug did more than was agreed.
> 
> So, we should first - as a matter of procedure - revert the part of the
> change which was not agreed and *then* get to discussion of further changes
> people would like.

When implementing the change, there was no known use case for destinationURL in createSession() other than default URL. Rather than define what may be used to generate the URL, it was simpler to just specify "null". I disagree that the editors need approval for every such decision. We are now discussing use cases and alternative solutions, which I believe is a good outcome of that decision.

> > It seems wrong that the CDM should be able to tell the application to use a
> > server that is not its own. The assumption for the other uses of
> > destinationURL is that the URL comes from the license. In that case, the
> > license server (likely controlled and configured by the application author)
> > can specify a different URL for certain messages (i.e. heartbeat). With
> > default URL removed, maybe a better solution would be to replace
> > MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute,
> > which would allow the application to select the appropriate server from its
> > list of servers. This would work for normal messages, heartbeat, and
> > initialization.
> 
> Personally I have no strong opinion about what the field is called so long
> as it is a free-form string or ArrayBuffer, rather than an integer. I've a
> preference for it to be called something which implies the intended usage is
> to influence the routing of the keymessage.

I filed bug 26683.

(In reply to David Dorwin from comment #17)
> (In reply to Mark Watson from comment #16)
> > (In reply to David Dorwin from comment #15)
> > The point here is that we had a stable design (CDM sets destinationURL in
> > keymessage event) which several people had determined was sufficient for
> > their use-cases, even if those use-cases were not spelled out in the
> > discussions.
> 
> The spec is subject to change and improvement:
> "Implementers should be aware that this specification is not stable.
> Implementers who are not taking part in the discussions are likely to find
> the specification changing out from under them in incompatible ways. Vendors
> interested in implementing this specification before it eventually reaches
> the Candidate Recommendation stage should join the mailing list mentioned
> below and take part in the discussions."
> 
> There are no guarantees in this phase that incompatible changes won't be
> made, especially if they improve security, privacy, and interoperability or
> address architectural issues. Scenarios that have not been disclosed or
> adequately described to the group are especially likely to be impacted. 
> 
> > We did not agree to change this aspect of the design. We agreed to remove
> > the requirement that destinationURL be set equal to the defaultURL from the
> > initData. The change associated with this bug did more than was agreed.
> > 
> > So, we should first - as a matter of procedure - revert the part of the
> > change which was not agreed and *then* get to discussion of further changes
> > people would like.
> 
> When implementing the change, there was no known use case for destinationURL
> in createSession() other than default URL. Rather than define what may be
> used to generate the URL, it was simpler to just specify "null". I disagree
> that the editors need approval for every such decision. We are now
> discussing use cases and alternative solutions, which I believe is a good
> outcome of that decision.

Of course I am aware of the boilerplate around the status of the specification. Also the latitude afforded to Editor's to make proposals in advance of obtaining approval or consensus. However, that latitude should not extend to making changes which are clearly controversial or where there is explicit disagreement.

I'm not sure how clear the status was with this bug, but what I remember is that there was considerable opposition to the whole thing and that this opposition evaporated when it was clarified that destinationURL would not be removed from the message event and so could still be set by the CDM (this is what I understood Comment #9 to say, but I see you could interpret the 'i.e', rather than 'e.g.' as implying an assumed restriction as to when the CDM can set this to a non-null value).

Anyway, we are going to need a way for the CDM to provide routing information for messages. The alternative is that CDMs defined key-system specific message formats with a routing part and a message part, where the routing part is visible to the client application, or just that there are non-compliant EME implementations where the destinationURL field is not null here.

> 
> > > It seems wrong that the CDM should be able to tell the application to use a
> > > server that is not its own. The assumption for the other uses of
> > > destinationURL is that the URL comes from the license. In that case, the
> > > license server (likely controlled and configured by the application author)
> > > can specify a different URL for certain messages (i.e. heartbeat). With
> > > default URL removed, maybe a better solution would be to replace
> > > MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute,
> > > which would allow the application to select the appropriate server from its
> > > list of servers. This would work for normal messages, heartbeat, and
> > > initialization.
> > 
> > Personally I have no strong opinion about what the field is called so long
> > as it is a free-form string or ArrayBuffer, rather than an integer. I've a
> > preference for it to be called something which implies the intended usage is
> > to influence the routing of the keymessage.
> 
> I filed bug 26683.

Let's continue the discussion there.

As discussed in the telecon yesterday and above, we will continue discussion in bug 26683.

*** Bug 26401 has been marked as a duplicate of this bug. ***