[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 #53 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #49)
> Prompting on a per-site basis may sound good, but the user experience is so
> poor around this (partly for the reasons you mention) that I don't see how
> it can work. 

I think the number of sites using DRM that a user interacts with is likely to
be small. Also, the UX issues can be mitigated. This issue is not unique to EME
or even web APIs - native mobile apps also have per-app prompts to give users
control.


(In reply to Mark Watson from comment #50)
> Note that, except in the case that the attacker is an authorized user of the
> keysystem, #5 and #6 are addressed if - as discussed in the privacy section
> - the keymessages are encrypted to the server, which itself is authenticated
> by means of a server certificate.

There is no such normative requirement in the spec, especially one that the
user agent can verify or enforce. Even with encryption, the identifier must be
effectively anonymized, which requires careful thought in the implementation. A
secure origin is something that the user agent can enforce and verify instead
of relying on the CDM vendor to do the right thing and do it correctly.

> Also, attacks equivalent to #5 and #6 are already generally possible without
> EME using fingerprinting, information stored on the client by the attacked
> site etc. Adding EME makes no difference provided the other mitigations for
> #1-#4 are in place.

I think its misleading to compare the identifiers DRM systems often use to
fingerpriting or local storage. In the worst case, DRM systems exposes a
permanent non-clearable cryptographic identifier tied to the hardware. Even
reinstalling the OS (if possible) may not clear the identifier. This is much
stronger than fingerprinting or local storage.

There are mitigations, but those are not normative either.

> Commercial CDNs charge significantly more for HTTPS services than HTTP.
> Migrating a large amount of traffic from HTTP to HTTPS has significant
> capacity / re-engineering implications. There are also operational issues
> that negatively impact user experience. So it's a significant issue.

The cost and other issues are something that will need to change as more of the
web moves to HTTPS. EME is likely to be around long after that happens. There
may be a slight overhead (see https://istlsfastyet.com/), but charging
"significantly more" seems unreasonable. Maybe there is a market opportunity
for some CDNs.

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

Received on Thursday, 21 August 2014 21:04:24 UTC