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

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

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

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

Received on Monday, 7 July 2014 16:46:15 UTC