[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 #22 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Anne from comment #21)
> Actually that is false. A standard can definitely require that an API is
> only exposed on secure origins, even if that API requires further user opt
> in.

The goal of this is interoperability.

Can EME, devoid of any context about the particular CDM implementation, be
analyzed to ensure it protects the privacy and security of users?

David sets out in the description that the security analysis of EME cannot be
decoupled from particular CDMs, which Mark states that they cannot (in Comment
#6) and Jerry also expresses, albeit indirectly, in Comment #15.

However, the CDMs are non-standard, nor necessary guaranteed to be
interoperable, which Bug 20944 is tracking. As a result of this, a web
developer who wishes to use a CDM/EME has no guarantee whether or not it
provides a sufficient level of security for a UA to enable it, nor does a web
user have the necessary context to review and decide regarding EME on its
merits alone.

Further, because of the EME/CDM split, it's likely (as we can see even from the
comments by UAs on this bug) for two vendors to disagree as to whether a
particular CDM is sufficiently secure for users - with one requiring a secure
transport (because key exchange or functionality is insufficiently handled)
while another permitting it on easily intercepted and manipulated channels such
as HTTP.

Given that Pervassive Monitoring is an Attack (BCP 188 / RFC 7258), it's
important for us to consider what are appropriate/best steps that can be taken
to:
- Ensure privacy of users, including privacy from fingerprinting
- Ensure security of users
- Ensure consistency and interoperability for developers using this spec
- Ensure consistency and interoperability of implementations of both EME and
CDMs

Despite Mark's claim in Comment #6, there are no normative requirements upon
User Agents preventing them from treating CDMs as generic plugins. The closest
approximation is the non-normative requirements in Section 6 (Security) and 7
(Privacy) that "CDM implementors must provide sufficient information and
controls to user agent implementers", but one can say that the exact same
requirements exist for plugins via <object> today.

Given the extensive number of ways for which privacy-sensitive data can be
disclosed, as per Section 7 (Privacy), it would seem that enabling this API via
HTTP would be akin to enabling authentication cookies over HTTP (i.e. without
the secure flag). Even if this information is for the duration of a "session"
(an ambiguous concept in practice), that's still enough to enable pervassive
monitoring of users.

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

Received on Tuesday, 12 August 2014 19:20:59 UTC