[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 #126 from Henri Sivonen <hsivonen@hsivonen.fi> ---
I'm still getting one-liner provocations on Twitter instead of a reply here. It
seems the main issue is a lack of a clear enough endorsement of https on my
part. So:

Restricting EME to https-only in the sense of the origin using EME and the
origins of the ancestor browsing contexts being https origins only would be a
significant improvement to the Key System-independent privacy characteristics
of EME. (As noted, you fall short of the goals if the ancestor chain isn't part
of the restriction.) If Microsoft and Google (the browser vendors who we have
to thank for the existence of EME and who are prominent DRM vendors in addition
to being browser vendors and, therefore, in a particularly strong position when
it come to EME) actually shipped that way, that would be awesome assuming there
are no non-EME ways to do identifier-exposing DRM e.g. via ActiveX, NPAPI or
Pepper plug-ins that MITMs could poke instead.

I think exposing a permanent or origin-independent identifier to the other end
of the TLS pipe would be a problem still, so I still think Mozilla-style
partitioning of the CDM identity should be recommended even with https.

As long as the https requirement is a dead letter of the spec and Microsoft and
Google actually ship with http permitted, users need other privacy solutions. I
think an https goal should not be allowed as an excuse not to recommend how
equivalent or almost equivalent privacy properties could be achieved on the Key
System layer.

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

Received on Thursday, 30 October 2014 09:55:34 UTC