[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 #104 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #103)
> Regarding the TAG opinion, as well as being just that and being worded as a
> recommendation, it was clearly conditional: "To the extent that
> privacy-invasive or security-compromising features can be normatively
> disallowed, EME should do so. _To the extent that they cannot be_, e.g. for
> robustness reasons, we _should_ restrict access to those features such that
> they can only be used from secure origins".

It is more than an opinion - it a spec review adopted by the TAG. Note its new
location [1].

I'm not sure why you added emphasis to "should." That is the English word
"should", not RFC "SHOULD", and refers to the W3C, not user agents.

> So, to truly follow their recommendation we would need to determine the
> extent to which privacy-invasive and security-compromising features can be
> normatively disallowed before we could conclude on the circumstances in
> which a secure origin restriction provides value.

We have identified broad privacy-invasive and security-compromising
issues/functionality/features that are not currently normatively disallowed.
Since those privacy-invasive and security-compromising issues and features are
not normatively addressed and disallowed, respectively, we should restrict
access to secure origins.

Despite repeated requests, there have been no concrete proposals (other than
Clear Key and intranets, which is currently being discussed [2]) for normative
definitions of features or circumstances for which a secure origin restriction
does not provide value. How long should we have waited before fixing the
privacy and security holes in the spec? The longer we wait, the more difficult
it will be for everyone to adapt and the more vulnerable implementations will
ship.

> Furthermore, recent discussion on the TAG list suggests perhaps they have
> not actually fully absorbed the work we have already done on privacy and
> security. They also say, elsewhere '... privacy-sensitive features, a
> category that EME definitely falls into...' suggesting they have not
> understood at all the conditions under which EME is no more
> privacy-sensitive than cookies.

What work have we done on privacy and security? The non-normative
considerations sections? Those have not received much attention when or since
you wrote them, and there is still an issue in the spec stating they are
incomplete. Regardless, they are not a replacement for normative text.

The text you quoted was mine from comment 91; the TAG resolution, which begins
with the word "RESOLUTION."

Your assertion that "In practice there's no reason for EME in browsers to be
any more privacy sensitive than regular cookies" [3] (or that this is even
likely to be true for a majority of implementations) has been debunked in the
www-tag thread [4].
The focus on theoretical possibilities and apparent unwillingness to address
real concerns presented by real implementations has been a major hurdle to
progress on this issue. I understand that some people are strongly opposed to
requiring secure origins, but we cannot continue to stick our heads in the sand
and hope for a good outcome on important security and privacy issues.


[1] https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md
[2] http://lists.w3.org/Archives/Public/public-html-media/2014Oct/0085.html
[3] http://lists.w3.org/Archives/Public/www-tag/2014Oct/0081.html
[4] http://lists.w3.org/Archives/Public/www-tag/2014Oct/thread.html#msg77

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

Received on Saturday, 25 October 2014 02:16:06 UTC