[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 #103 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #101)
> (In reply to Glenn Adams from comment #100)
> > (In reply to David Dorwin from comment #97)
> > > This one-line change does not prevent collaboration, but it does fix a
> > > security and privacy problem with the spec and bring it inline with the
> > > TAG's direction, which in turn brings it closer to moving forward in the
> > > spec process.
> > 
> > The TAG's input is just input. It doesn't mean that we must follow it. Given
> > the significant opposition to the "one line change", it would be best to
> > remove it until there is WG consensus on how to proceed. As editor, you
> > serve at the behest of the WG.
> 
> The significant opposition is from a few people and is not necessarily
> representative of the WG. There has also been strong support for such a
> change.
> 
> I considered input from the TAG, WG, and other W3C members and updated the
> text in the Editor's Draft. This is consistent with the HTML WG's Real Work
> Modes (https://www.w3.org/wiki/HTML/wg/WorkMode#Editors). WG consensus will
> not be required unless/until the WG formally publishes the specification as
> a Last Call Working Draft. Hopefully we can address some of the concerns
> before then.

As a co-editor, the way I interpret that process is that _ultimately_ we are
operating on a consensus-based model (as distinct from the WHATWG process, for
example). That means that, pragmatically, there is no point in making changes
which are known to be highly controversial since it serves only to annoy people
and thus stall progress. It's at least disrespectful to the goal of
consensus-building.

I have no interest in participating in a standardization process that is not
ultimately consensus-based - that's an oxymoron as recognized at
open-stand.org.

Also as a co-editor, I guess I could just revert it myself, but commit wars are
silly. Best not to start them.

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".

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.

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 committed https://dvcs.w3.org/hg/html-media/rev/be9998cf708c to add an
> issue box referencing this bug and the open questions.

That's not sufficient. Please revert the change and we can continue the
technical discussion. I actually thought we were starting to make some
progress.

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

Received on Saturday, 25 October 2014 00:41:43 UTC