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

The point is that the *spec* provides no such guarantees OR restrictions, in
which case, evaluating the *spec*'s privacy and security considerations cannot
be done, because there is information and context lacking.

This absolutely affects the ability of the W3C to adequately review and
understand the spec, as withholding details ("It's up to the CDM"), 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.

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

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

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

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

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

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

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.

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.

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.

Failing to say anything is to require HTTP be supported, which is
unquestionably harmful to security and privacy.
Failing to require HTTPS is equally a failure to guarantee interoperability
according to the spec.

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

Received on Tuesday, 19 August 2014 17:44:46 UTC