[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 #36 from David Dorwin <ddorwin@google.com> ---
It has been argued that user agents will do what is right (for the CDMs they
support) and that there is therefore no need to require HTTPS. I do not believe
this would be true in practice.

I think it is unlikely that most user agent implementors will have access to or
seek out the information necessary to make the correct decision. (Think beyond
the major browser vendors.) I think the spec can and should try to avoid such
judgement calls on important issues.

Furthermore, suppose that a user agent implementor does not feel comfortable
with the capabilities of the CDM (i.e. one built into the platform). They
_could_ choose to require HTTPS, but if all other implementations have not made
that requirement, the user agent will likely be limited to a small set of
content providers that support HTTPS. Instead, that implementor will probably
expose the CDM to HTTP anyway, resulting in exactly the problems we are trying
to avoid. As I said above, "it is likely that the only way to actually address
the issue is to normatively require secure origins..."


Much of the discussion has focused on identities, but there are other concerns
as well. For example, DRM implementations, especially those provided by the
platform, are often unsandboxed. This means that such CDMs could access
anything on the system and it are particularly dangerous because they run
outside the sandbox. Given these risks and the unique nature of EME/CDMs
compared to other web APIS, it makes sense that such risks should be restricted
to authenticated domains.

Other potential mitigations to these risks (i.e. prompt the user) are also
non-normative, so we cannot rely on those. Even if we made user prompts
normative, the benefit is minimized if non-secure origins are supported (see
[1] in comment #0).

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

Received on Tuesday, 19 August 2014 21:21:09 UTC