[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 #109 from Mark Watson <watsonm@netflix.com> ---
(In reply to Ryan Sleevi from comment #108)
> (In reply to Glenn Adams from comment #105)
> > (In reply to David Dorwin from comment #104)
> 
> Regardless, it's clear from this bug that the opponents towards a secure
> origin requirement are not making concrete suggestions for dealing with
> these privacy concerns. The only options that have been put forth so far are
> doing nothing in the spec - which is ignoring the problem entirely - or to
> place a requirement in the spec for secure origins, and then work towards a
> consensus that can alleviate these concerns. Since it's clear that "doing
> nothing" is not an acceptable solution for anyone, from the TAG, to UAs, to
> users, the onus needs to be on those who object to secure origins to make
> concrete and actionable proposals to reduce that. But if no proposals can be
> made, secure origins are logically the least that a UA can do to address the
> concerns.

There are mitigations to all the concerns described in the document (and if not
there, in this and other threads, I believe). We can and should discuss the
normative strength of those, as I have repeatedly said. We are at the very
beginning of this whole discussion, not the end.

But in the end, the onus is on browser vendors to provide a viable solution
because if the solution you provide is not viable - financially, say - sites
will not use it. HTTPS is not there yet, as I've explained. We need
alternatives - which for this problem clearly exist - and / or a reasonable
industry plan to make HTTPS sufficiently reliable and efficient at scale.
Sticking your head in the sand and expecting standards fiat to achieve that is
not productive.

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

Received on Monday, 27 October 2014 02:55:30 UTC