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

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

--- Comment #2 from David Dorwin <ddorwin@google.com> ---
(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

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

Received on Friday, 6 June 2014 23:43:28 UTC