[Bug 26683] Replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute

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

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

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

Received on Wednesday, 17 September 2014 21:14:44 UTC