[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 #26 from Glenn Adams <glenn@skynav.com> ---
(In reply to Ryan Sleevi from comment #25)
> (In reply to Mark Watson from comment #24)
> > 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. 
> 
> In the W3C, there has been a priority of constituentcies that inherently
> recognizes the reality of multiple stakeholders being party to the
> conversations. Users, developers/authors, implementers are all part of the
> equation.
> 
> It sounds like you are stating that only UAs can or should be part of the
> security and privacy analysis, and that seems to run counter to the W3C's
> goals of being an open and transparent organization.

To the extent that UAs do not support user installable CDMs, then Mark is
correct.

In any case, what UAs do with CDMs has no bearing on the W3C as an "open and
transparent organization".

> 
> > This is not an open plugin API with user-installable CDMs.
> 
> While I appreciate you making this point, I feel that this is just your
> opinion. Both of your co-editors, and their respective organizations, have
> positioned EME/CDM as precisely that, both in public discussions and, on a
> more practical matter, within the code itself.

Whether CDMs are an open plugin API or not is the decision of the UA vendor.

> 
> On Microsoft's side, while the goal is to explicitly support PlayReady, it
> maps onto the more generic Media Foundation APIs -
> http://msdn.microsoft.com/en-us/library/windows/apps/dn466732.aspx
> 
> On Google's side, EME/CDM is exposed through the Pepper plugin interface,
> Google's replacement for NPAPI. Indeed, even the existing EME
> implementations in Chrome are progrmatically no different than generic
> plugins.
> 
> I think if you wish to support this view, it may be necessary to have the
> spec state so.

The spec will not place requirements on UAs with respect to how they choose to
support CDMs. If you would like to write another spec that does so, then you
may draft and submit it for consideration.

> However, I think such a statement would likely prove harmful
> to the spec overall, as much of the discussion related to this spec has been
> whether or not it's tangibly different than the <object> tag. Your statement
> - which is that CDMs are UA-specific - would seem to support an
> intentionally far less interoperable view than many W3C members have
> realized.

Mark is not stating that it is intentional. At this point, it is just a
historical fact, not predicated or influenced by the spec.

> 
> 
> > 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.
> 
> Mark, I'm sure you can see that, unlike the same-origin policy or other
> security relevant features, it is a by-design goal of the authors of this
> spec that the capabilities of a CDM be opaque to the general public and
> authoring community, beyond that which the CDM author shares. Unlike the
> same origin policy, this makes it difficult to evaluate the security and
> privacy context in which these CDMs operate.

The authors of the EME spec are the HTML WG, not the editors. It is certainly
not true that it is a by-design goal of the WG that the capabilities of a CDM
be opaque.

CDMs operate as an integral (or integrated) part of a UA; therefore, they are
as opaque or as transparent as the UA vendor chooses to make them. If a UA
supports installable CDMs, then it is up to the installer to determine their
level of trust by whatever means they require. This is SOP for the Web today.

> 
> Considering that you and your fellow authors have listed a number of
> capabilities being exposed to CDMs that are otherwise not exposed to the web
> (except via the <object> tag), which carry with them significant privacy
> risks and support for permanent device identifiers, I think it's a bit
> disingenuous to compare a privacy net-negative with features designed to
> bolster security, or to suggest that users should fully rely on the UA to
> assuage their privacy concerns for a spec developed publicly and with the
> intent of being a W3C document.

A user that entirely relies upon a UA to "assuage their privacy concerns" is
simply ignorant of the risks that exist in either the pre-EME world of media or
the EME world. EME and CDMs don't change this fact.

> 
> > 
> > > 
> > > 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.
> 
> I don't feel this satisfactorily deals with the issue, unless you believe
> that a lack of interoperability is a goal or feature of this specification.

Nobody thinks that lack of interoperability is a goal or feature. That's just a
silly statement.

> 
> It would seem, based on the significant feedback from the community, that
> having two or more UA vendors ship the same CDM is a highly desirable
> outcome.

Sure. If EME is ever going to be successful in anything other than vertical
silos, then there will need to be some commonly supported CDMs.

> As such, it does not seem you can reasonably ignore or dismiss this
> issue, unless you believe that UA vendors should not ship interoperable CDMs.

You are talking apples and oranges. This issue (requiring HTTPS has nothing to
do with interoperability).

> 
> 
> > > 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. 
> 
> I'm not sure - are you suggesting that this exists for CDMs? Or is this
> merely a statement to the effect that "Since you can't do it for NPAPI, you
> don't need to do it for EME"?
> 
> > Nor is there
> > any established practice of UAs whitelisting only those plugins for which
> > the security and privacy properties are understood. 
> 
> There has been, for some time, such a practice.
> 
> http://www.chromium.org/developers/npapi-deprecation
> http://blogs.msdn.com/b/ie/archive/2011/02/28/activex-filtering-for-
> consumers.aspx

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

Received on Tuesday, 19 August 2014 16:51:17 UTC