[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 #122 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #117)
> (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.

I don't disagree with any of the above. However, if you don't trust user agents
to take sufficient precautions for user security and privacy you have bigger
problems, surely.

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

This has been a 3-year project during which we've made significant changes to
our service to accomadate HTTP-specific privacy concerns raised by browsers. I
think if the secure origin requirement had been known from the beginning we
would be in a different place.

But, yes, browsers are free to disable services they feel are unsafe, whether
that is by disabling plugins, which could have been done at any time, or by
disabling any other functionality on which in-the-field services depend.

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

Whilst I don't agree with your characterization of Jerry's comment, I agree
there are disagreements. That's why we need to continue the discussion so that
at least we are all on the same page with the facts. Indeed digging more
rigorously into the specific cases and properties is exactly what I have been
suggesting.

> 
> >> 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],

No, I said that the system could be designed so that the privacy properties
were not worse than cookies. I think that's correct. It suggests that HTTPS is
not required _in all cases_, not that there is no problem.

> discredit the TAG’s analysis [4],

Comment #107 was entirely factual.

> and restrict analysis to a small subset of
> implementations [5] rather than finding ways to solve them.

Again, I think your expectations as to the speed of this process are
unreasonable. There is no objection on my part to diggging deeper into the
problem. We invested in collecting data to inform the discussion.

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

I stand by all those statements. The solution we have in the field is a major
improvement over what we had before. It's taken us 3-4 years of work to get
there. I understand you want to go further, but I'm arguing that is not
possible overnight.

I haven't rejected the TAG's review at all, I just disagree with your
interpretation of it. As I said, it asks that to the extent the issues cannot
otherwise be mitigated we should require a secure origin. I'm arguing that it's
important to figure out how the issues can otherwise be mitigated because a
secure origin is not a viable solution in the short term (unless the
sub-resource integrity thing can be made to work, that is).

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

I agree. So, since we seem to be saying the same thing, why don't we all commit
to take seriously the issues raised by the other participants and to invest in
discussing those until we get to a resolution ? You could demonstrate that
commitment by reverting the change.

> 
> [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 02:47:26 UTC