[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 #117 from David Dorwin <ddorwin@google.com> ---
(In reply to Ryan Sleevi from comment #112)
> (In reply to Mark Watson from comment #111)

> > The repeated suggestion that we do not care about user privacy or security
> > is, frankly, quite tiresome. This whole effort, over the last four years on
> > my part, has been about migrating from the wild west of plugins to a model
> > where this functionality is provided by User Agent implementors and so,

While some desktop implementations are better than plugins, that doesn’t mean
the spec or implementations are at a level appropriate for the web platform.
Other clients will be exposing functionality to the drive-by-web that was
previously only available to native installed apps. With only three
implementations, all on desktop browsers, there are already questions whether
adequate privacy and security precautions have been taken. That demonstrates
that there is reason to be concerned, especially as EME is implemented in more
user agents on more platforms.

One DRM vendor has said “I don’t believe you can have DRM without an exchange
of PII. That is the nature of DRM.” [1] There is clearly a record of privacy
issues that need to be addressed before DRM is exposed to the web without
plugins.

> > amongst other important things, privacy and security are in the User Agent
> > implementors' hands. And in practice this has already been achieved for
> > desktop IE, Safari, Chrome and in due course I expect for Firefox, all over

You argue that because these browsers have implemented EME over HTTP that this
must be okay. Yet, it is clear that if any of those browsers had chosen to
require a secure origin, they would not be supported via HTML5 by Netflix and
others [2].

> > HTTP
>> and with the User Agent implementors fully aware of the privacy
> > properties.

Comment #113 calls this logic into question, or at least shows there are
disagreements about the privacy properties. 

>> It's hugely disappointing to see this jeopardised just as it's
> > coming to fruition. 
> 
> It's clear that you don't care to the same degree we do, or value it to the
> same degree we do, otherwise this discussion would be moot. Nor is anything
> being jeopardized - EME continues to progress, and the deficiencies in the
> spec with regards to privacy and security are slowly being addressed,
> although in ways that some are not happy with.

Seconding this, it’s hard to argue that you care about these things when most
of the effort so far has been to deny that the problems exist [3], discredit
the TAG’s analysis [4], and restrict analysis to a small subset of
implementations [5] rather than finding ways to solve them.

When people opposed the W3C working on EME, you touted improved security and
privacy, including from W3C review [6] and said that “EME is about
*constraining* DRM on the web and subjecting it to more public, open, privacy
and security review” and referred to “W3C supervision” [7]. However, now that
we have such review and it is incompatible with your desires, you and others
reject it.

> > An open standardization process is not only about documenting interoperable
> > behavior - a private group of UA implementors could do that on their own
> > with much less overhead. It's about committing to take seriously the
> > concerns of multiple stakeholders, to keep on working until there is
> > consensus, and in deference to the value that brings a willingness to accept
> > consensus-based outcomes.

It’s also not about documenting behavior of existing implementations regardless
of the security, privacy, and interoperability properties. UA-DRM vendor pairs
could also do that on their own and tell content providers how to write
applications for their solution. It is about committing to take seriously the
security and privacy of users and to maintain the one web platform. That is why
we are at the W3C, getting the kind of supervision you alluded to in [7].

[1] http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0087.html
[2] “browsers who choose to support only HTTPS will find their customers either
still using plugins, or cut off from services - a different kind of
fragmentation of the web.” -
http://lists.w3.org/Archives/Public/www-tag/2014Oct/0096.html
[3] i.e. http://lists.w3.org/Archives/Public/www-tag/2014Oct/0081.html
[4] i.e. Comment #103, Comment #107
[5] i.e. Comment #111
[6]
http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Oct/0034.html
[7]
http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Aug/0036.html

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

Received on Wednesday, 29 October 2014 01:01:14 UTC