[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 #31 from Glenn Adams <glenn@skynav.com> ---
(In reply to Ryan Sleevi from comment #27)
> (In reply to Glenn Adams from comment #26)
> > (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".
> 
> Glenn,
> 
> You cannot say that the spec doesn't support user-installable CDMs, and then
> later say it's up to the UA.

Sure you can. The spec is silent on whether a CDM is user-installable or not.
Therefore, it is up to the UA.

> 
> The point is that the *spec* provides no such guarantees OR restrictions

So? No W3C spec provides any guarantee... the W3C does not certify products
that implement its specifications.

, in
> which case, evaluating the *spec*'s privacy and security considerations
> cannot be done, because there is information and context lacking.

Sure it can (evaluate). And yes, it will never be complete, because information
and context is always lacking (from any spec). Only an implementation of the
spec can be fully evaluated.


> 
> This absolutely affects the ability of the W3C to adequately review and
> understand the spec,

Sure it does. And that is by design. CDMs are explicitly out of scope of EME.

Your problem is that you don't seem to agree with this decision. But it holds
and will not be changed.

> as withholding details ("It's up to the CDM"),

There is no "withholding details". There are simply "implementation details
that are out of scope". You are talking to the wrong people. If you want to do
a security and privacy analysis of a CDM in a specific UA then you need to be
talking to the CDM and UA vendor. Your comments are misdirected if you think
they will be addressed by EME.

> with no
> definition for how those CDMs are evaluated, AND with the express statement
> that CDMs can only be evaluated by UAs, directly prevents those interested
> in privacy and security from providing meaningful feedback as to how the
> spec guarantees or inhibits these.

W3C specs do not guarantee or restrict UA behavior. They may do whatever they
want, and in fact, they do.

> 
> > Whether CDMs are an open plugin API or not is the decision of the UA vendor.
> 
> This may be, but it has direct bearing on the interoperability and
> applicability of this spec.

The same statement can be made for every W3C specification. For example, the
HTML5 specification does not require support for: JavaScript, CSS, any specific
image or media format, and a myriad of other features.

> 
> > 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.
> 
> This response fails to address the original issue which Mark was deflecting.
> It entirely be the view of the WG that you choose to fail to address this,
> in which case, it should be unsurprising if objections are raised.

The WG is not going to revisit the decision of determining that CDM details are
out-of-scope. You can object, but it will serve no purpose.

> 
> This is an opportunity to improve the spec. Let's take it.

No and No. It will not improve the spec (and in fact will damage it). And No
the WG will not revisit the decision that CDMs are out of scope.

> 
> > Mark is not stating that it is intentional. At this point, it is just a
> > historical fact, not predicated or influenced by the spec.
> 
> This is odd, because you just stated as much in the above quoted reply.

You said:

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

This pertains to whether UAs are intentionally UA-specific or not. Mark was not
saying that "UAs are intentionally UA-specific". If they are (at the moment)
then that is a historical coincidence and has no necessary relation to the spec
or future implementations.

> It's
> absolutely influenced by the spec and whether or not it will or will not
> place normative requirements, and the absence of these requirements affects
> the ability to review the security, privacy, and interoperability guarantees
> of the spec.

Sure. But you are merely stating the obvious: "that not defining CDMs means
that the security and privacy consideration of CDMs cannot be evaluated". That
is a consequence of ruling that CDM details are out of scope of EME. That can't
be helped.

> 
> > CDMs operate as an integral (or integrated) part of a UA; 
> 
> "The spec will not place requirements on UAs with respect to how they choose
> to support CDMs"
> 
> These two statements are in conflict. Either it's an integrated, integral
> part of a UA, or it's not.

No these statements are not in conflict. If a CDM is integrated, then the UA
ships with the CDM. If a CDM is from a 3rd party and can be installed after the
UA ships, then it is not integrated. The spec doesn't restrict whether a UA
supports only one or both of these models. The spec only requires that every
implementation of EME provide an integrated CDM that implements the
org.w3.clearkey key system. Beyond that, it is up to a UA vendor.

> 
> > > > 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.
> 
> Then you can't deflect an interoperability concern with the response "Well,
> it's not a concern because there isn't interoperability".
> 
> If interoperability is a concern, then this is an issue, and it has to be
> dealt with. The only reasonable reason not to deal with it if
> interoperability is not a goal.

You seem to imply that interoperability is black or white. Interoperability is
always a gray scale. One of the levels of interoperability is whether the
publicly defined EME interfaces interoperate under certain constraints. Another
level is whether and end-to-end media stream will interoperate between a given
server and distinct UA (and CDM) implementations. The former is clearly in
scope for EME; the latter is clearly not in scope. You seem to be wanting to
make the latter in-scope, but it isn't: by definition.

> 
> > > 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).
> 
> If only this were the case!
> 
> If I, as an author, which to use EME on my page - an EME CDM that is
> implemented by multiple UAs (since we say interoperability is a goal) - then
> what do I, as an author, need to do to enable this?

I fully agree with you, and wearing my hat as a service provider member (Cox
Communications) this is also our major concern for EME. However, we recognize
that their are boundaries of what EME can and should define and this has to be
considered in the wider context of the fact that the W3C does not publish
conformance tests and does not assess the compliance of implementations.

> 
> Can I deploy it over HTTP and be assured it will work by all UAs that
> implement the CDM and conform to the spec?
> 
> The answer is certainly no.

Agreed. But you will never get such a guarantee in the context of W3C. Go start
and fund a consortium to publish and perform compliance tests, then award
labels to products that pass. After you do that, let us know how it turns out.

> 
> If I deploy CDM A, which works with UA A, and then later choose CDM B, which
> works with UA's B and C, where CDM A/UA A worked over HTTP, can I be assured
> that my switch to CDM B, fully conforming to this spec, will work?
> 
> The answer is certainly no.

No argument here. But this is not relevant to this issue.

> 
> These are real interoperability concerns. Whether or not this API works over
> insecure transports and insecure origins, whether or not it sufficiently
> protects privacy, these are all things authors and implementors have to
> consider.

Sure.

> 
> Failing to say anything is to require HTTP be supported

No it isn't.

>, which is
> unquestionably harmful to security and privacy.
> Failing to require HTTPS is equally a failure to guarantee interoperability
> according to the spec.

Requiring HTTPS does not guarantee interoperability.

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

Received on Tuesday, 19 August 2014 18:32:58 UTC