[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 #56 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #53)
> (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.

You are correct that this is not unique to EME. However in user testing we have
seen significant falloff in completion rates in using any web application that
requires a user opt-in to run. I think a normative requirement for this type of
opt-in prior to using the API will result in very low usage of this API. I
could be wrong though -- there could be some amazing UX out there for this I
have not seen. But it is not in Chrome, Firefox, Internet Explorer or Opera. 


(In reply to Ryan Sleevi from comment #54)
> (In reply to Mark Watson from comment #50)
> As for the claims of SSL adding additional overhead or latency, I would
> encourage members to read
> http://tools.ietf.org/html/draft-mattsson-uta-tls-overhead-00 (for which an
> update is already being prepared), that looks at the practical real-world
> overhead and shows that it's virtually non-existent.

The overhead is not zero. And when you are having large numbers of transactions
compressed into a small window the overhead can have a significant impact. Not
to mention that SSL introduces additional failure modes as Mark mentioned
earlier. 

> This is unquestionably a diversion from the main crux of this bug - which is
> whether a secure transport MUST (normatively) be required, due to the
> complex and potentially (and probable) privacy impact of EME - but if the
> argument is that TLS is not viable, well, the evidence at present is that
> this is not the case, and will continue to be even less of a viable argument
> over time.

I don't think we are arguing that TLS is not viable (at least I am not). I am
arguing that HTTP with message-based encryption is equally viable and has
certain advantages. We should allow implementations to leverage those
advantages when they want to.

There is a good writeup on a weakness specific to SSL/TLS here --
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity. 
Perhaps ironically, the tightly controlled message-based encryption used by
many DRM are not subject to these issues and thus are more secure than SSL in
this sense at least.

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

Received on Thursday, 21 August 2014 22:01:33 UTC