[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 #24 from Mark Watson <watsonm@netflix.com> ---
(In reply to Ryan Sleevi from comment #22)
> (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?

No, but there is no need for anyone to do such an analysis. The UAs
implementing EME all know what CDMs they are integrating with and their
security and privacy properties. This is not an open plugin API with
user-installable CDMs.

> 
> 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.

As with any other API, both the user and the web developer rely on the UA to
protect their security and privacy. They should have the same guarantees with
respect to EME as they have with respect to the same-origin policy, for
example.

> 
> 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.

I don't think we have had such a disagreement as no two UA vendors are
presently integrating the same CDM.

> 
> 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.

I think the security and privacy issues that you are raising prevent exactly
that. We can discuss turning some of the security and privacy considerations
into normative requirements if you like.

> 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.

Not at all. There is no mechanism for UA implementors to obtain information
from NPAPI plugins as to their security and privacy properties. Nor is there
any established practice of UAs whitelisting only those plugins for which the
security and privacy properties are understood. This is the problem with NPAPI
plugins!

> 
> 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, 19 August 2014 15:51:46 UTC