[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 #121 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #118)
> (In reply to Joe Steele from comment #116)
> > I don't believe it is useful to continue the conversation until this change
> > is reverted. It would be worth spending my time to come up with a better
> > solution only if there were some guarantee that that solution would at least
> > be be considered. By forcing controversial changes in without consensus, my
> > confidence that any proposals I might make will be considered has been
> > sorely shaken.
> 
> I'm not sure why you feel your solution would not be considered. I have been
> asking for proposals for months (i.e comment #63) and reiterated this when I
> made the change (comment #92). It's ironic that people are threatening not
> to contribute to improving the spec until this change is reverted - it was
> the lack of constructive contributions that left us with this as the only
> concrete proposal. I continue to be willing to consider proposals for
> normative solutions or ways to reduce the impact on content providers.
> 
> However, I am concerned that it is not worth any of our time working on a
> spec that will never progress because a small minority without alternative
> solutions can block important security, privacy, and interoperability
> improvements necessary for EME to become part of the web platform. At least
> one browser vendor and the TAG, which includes the Director who considers
> Formal Objections, have strong objections to the previous lack of this
> requirement, which may endanger the WG's ability to reach Recommendation.
> While reverting the text might appease those that oppose requiring a secure
> origin and threaten not to participate, it would show a lack of regard for
> users and does nothing to move us closer to consensus or a publishable spec.
> Contributing “specific ideas for addressing the security and/or privacy
> concerns OR the impact on content providers” that I solicited in comment #92
> (and earlier) would do both.

Reverting the specification has nothing to do with the technical issues, but is
about demonstrating a commitment to a process which is ultimately
consensus-based and about a basic willingness to work constructively with the
other participants.

I don't know where you got the idea this was going slowly. It's a huge issue
that was raised only very late in a multi-year process. It's also hugely
controversial and controversial issues take time to resolve. A short time ago I
committed to provide some data, which had to be gathered and discussed
internally. I provided it on Friday, but you hadn't even waited for that.

I take exception to the suggestion that no alternatives have been proposed. I
have repeatedly suggested that we work rigorously through the cases and
understand the necessity and value of secure origins in each. I might not have
proposed alternative text, but there are proposed avenues as yet unexplored.

I'm more than happy to engage on the technical issues once the change is
reverted.

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

Received on Wednesday, 29 October 2014 02:18:52 UTC