[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

Joe Steele <steele@adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steele@adobe.com

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

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, 15 July 2014 15:55:32 UTC