[Bug 25920] Remove extraction of default URL from createSession() algorithm

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920

--- Comment #3 from Joe Steele <steele@adobe.com> ---
(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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 11 June 2014 09:33:12 UTC