[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 #25 from Ryan Sleevi <sleevi@google.com> ---
(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.

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

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


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

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.

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

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


> > 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:25:20 UTC