[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

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

--- Comment #7 from Mark Watson <watsonm@netflix.com> ---
(In reply to Joe Steele from comment #2)
> (In reply to David Dorwin from comment #0)
> > There is a push to require secure origins/transport for new powerful new web
> > platform features [4], which would include exposing permanent hardware-based
> > identifiers. Restricting the origin/transport is being discussed for other
> > APIs, including WebCrypto [5]. The definition of secure origin and transport
> > is still being debated, but it seems likely some standard definition will
> > emerge and could be referenced by EME.
> 
> This W3C Recommendation gives some good guidance
> (http://www.w3.org/TR/wsc-ui/#typesoftls) on what can be considered secure
> origins.
> 
> > Failing on insecure origins (e.g. HTTP) could take various forms. In all
> > cases, I think it makes sense to detect and handle this in
> > MediaKeys::create().
> > Possible options:
> > 1) EME APIs only work on secure origins: Always fail on HTTP, etc.
> > 2) Key systems that use unique identifiers only work on secure origins: Fail
> > if the implementation of |keySystem| uses identifiers.
> > 3) Key systems that do not have appropriate mitigations [3] only work on
> > secure origins: Fail if the implementation of |keySystem| uses identifiers
> > and does not have appropriate mitigations.
> > 
> > #1 is simple and consistent, but is perhaps too broad. For example, Clear
> > Key does not need HTTPS.
> > #2 will likely be equivalent to #1 for many implementations, but requires
> > the user agent vendor to proactively do the right thing. It is also perhaps
> > too broad.
> > #3 probably captures the right set of scenarios where the risk exists, but
> > it leaves a lot of room for judgement and incorrect decisions by user agents.
> 
> I am in favor of #1. 
> 
> However this could cause mixed security messaging, given that the media
> resources themselves are unlikely to be on secure origins for cost and
> performance reasons.

It's not just the messaging. Mixed mode is simply disallowed on some browsers,
so requiring a secure origin requires the media to be on a secure origin as
well.

 The key request origins may also not be secure (again
> for performance reasons) if the key request protocol uses message-based
> security rather than relying on a TLS channel. How would applications handle
> this?

Good question.

> 
> An easier problem -- what would failure mean here? Would this be handled
> with an error code?

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

Received on Tuesday, 22 July 2014 15:43:28 UTC