[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 #107 from Mark Watson <watsonm@netflix.com> ---
(In reply to Domenic Denicola from comment #106)
> (In reply to Mark Watson from comment #103)
> 
> > 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.
> 
> I categorically reject this characterization of our spec review and find it
> insulting.

I'm sorry, that was not my intention.

Let me restate my point in more factual terms:
- identifiers and EME is a complex topic, there are many different possible
scenarios
- we address these scenarios and give mitigations in our security and privacy
considerations, added under bug 22910 [1] about a year ago. We noted that
further review is expected.
- the TAG opinion does not go into details regarding different identifier
properties, it gives a blanket, though conditional, recommendation for secure
origins
- an author of the TAG opinion said 'individualization is not an area we looked
in to very much' [2],
- the same author expressed concern (and perhaps surprise) at the prospect of
EME identifiers being used as 'ubercookies' and suggested mitigations which are
already in the EME document [3]

We would welcome detailed feedback from TAG about the privacy section of the
document and particularly the normative strength of the mitigations.

By the way, requiring secure origins does not address the problem of
ubercookies, as Henri pointed out.


[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22910
[2] http://lists.w3.org/Archives/Public/www-tag/2014Oct/0080.html
[3] http://lists.w3.org/Archives/Public/www-tag/2014Oct/0106.html

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

Received on Saturday, 25 October 2014 16:11:44 UTC