[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 #105 from Glenn Adams <glenn@skynav.com> ---
(In reply to David Dorwin from comment #104)
> 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.

That is an absurd statement. Cookies suffer the same problem. Does that mean
they should be restricted 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.

Nobody is saying it can't potentially provide value. But value comes at a cost,
and there is an apparent majority in this TF that is saying the cost is greater
than the value within the near term.

> How long should we have waited before
> fixing the privacy and security holes in the spec?

Nobody is saying don't fix them. They are saying that the proposed fix is
impractical for at least some period of time, probably greater than one year in
duration. Should that hold up the work? No.


> The longer we wait, the
> more difficult it will be for everyone to adapt and the more vulnerable
> implementations will ship.

Implementations change all the time. So do specs. Even those of us who want to
see concrete, fixed RECs understand this thing called versions. I'm sure you
do. Perhaps EME1 can't and won't require security origins. Perhaps EME2 will.

The point is that it is necessary to build a consensus, and not simply adopt a
controversial position that discards the positions of the TF members. As
editor, you do not have that authority. If you want to have your position
adopted, you need to work in the accepted process, which may be to perform a
CfC within the TF and then the WG on this point. However, the way you are
responding is creating an unnecessarily tense and adverse working environment
in this TF by pursuing this point.

Please revert the recent change, then bring your position to the TF using
standard process in order to further discuss. The longer you delay doing this,
the more ill will you are generating.

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

Received on Saturday, 25 October 2014 03:55:08 UTC