[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 #49 from Joe Steele <steele@adobe.com> ---
(In reply to Ryan Sleevi from comment #47)
> (In reply to Joe Steele from comment #46)
> As a reminder, it's an entirely orthogonal issue as to whether two SITES
> receive the same identifier. An attacker in a privileged position on the
> network (as we have strong evidence of a number of nation-states and hostile
> entities being just that) can exploit a single site to obtain a persistent
> identifier to track that user as they browse and navigate.

I agree with you here. But trying to mitigate against this attack by THESE
attackers by requiring SSL is like adding a deadbolt to your front door when
the backdoor is a screen. SSL has its uses, but against a dedicated attacker it
is easy to work around. I can provide citations if you feel they are needed. 

> 
> When thinking about how best to protect privacy and security of users, our
> goal should not be the minimum possible ("how it is today"), but looking at
> how we can maximize this, while balancing risks ("how we SHOULD do it").
> Cookies have proven time and time again that we SHOULD do secure transports.

I agree here as well to a point. I think we need to balance the security
benefit we would get from requiring secure origin on these APIs (IMO small)
against the usability cost of this approach (IMO large). There is no perfect
solution here. 

If we do end up requiring this, I think all browsers are going to have to
drastically step up their game on handling of mixed-content applications and
probably we will need to provide new mechanisms (outside of this spec) to allow
this to be handled cleanly. 

(In reply to Henri Sivonen from comment #48)
> Which ones of these attacks is this bug about defending against? Are there
> additional attacks that this bug is about? Which ones of these attacks are
> CDMs deployed in IE, Chrome and Safari currently vulnerable to? What about
> the CDM that Opera demoed for "devices"?

Great questions. And my followup question would be -- how well would the fix
this bug proposes mitigate against these attacks? 

> Prompting the user to authorize the use of CDM on a per-site basis addresses
> attack #6 if the user has a good  grasp of what capabilities site is
> supposed to need and could address attacks #1 and #2 in cases where the CDM
> is only invoked for tracking purposes and there isn't actually any media on
> the sites that the user wants to play and the user has a good grasp of what
> capabilities a site with no media that the user wants to play is supposed to
> need.

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. 

> As far as I can tell, the main reason against restricting EME to secure
> origins only would be that it would make it harder for sites that don't
> already use secure origins to migrate from NPAPI-based DRM to EME-based DRM.
> How serious is this issue?

I don't believe that is the issue at all. IMO, the issue is that for
performance reasons the media streams are not delivered via secure origins. If
the app must be delivered from a secure origin, delivering the streams from an
insecure origin will result in mixed-content messaging. This is generally a bad
user experience. 

I am all in favor of having the app delivered from a secure origin (as I stated
in comment 2) if this issue can be dealt with somehow. I have not seen a
proposal for that yet.

>From a DRM perspective, I don't really care whether the key server is on a
secure origin or not. The additional encryption layer provides no additional
security over what my CDM will already provide, but it doesn't cause any
problems other than a performance degradation.

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

Received on Thursday, 21 August 2014 19:09:08 UTC