[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 #65 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #63)
> (In reply to Mark Watson from comment #59)
> > I know. Let me take a step back. Attacks #1 and #2 are not mitigated by
> > secure origin. Other mitigations as outlined in the privacy section need to
> > be in place.
> > 
> > What I said was - assuming those mitigations are in place - then what's left
> > of attacks #5 and #6 is no worse with EME than it is without EME.
> > Specifically, I did not compare non-clearable identifiers to fingerprinting
> > / local storage, I compared clearable, origin-specific, identifiers to those
> > things.
> 
> Are you arguing for possible option 2 or 3 in comment #0 or that we should
> normatively require the mitigations for attacks #1 and #2? The former still
> requires that Netflix and others support HTTPS for some of their traffic.
> The latter is not possible with many current DRM implementations (so you
> have the same transition issue).

I am curious. Why do you think it is not possible with many current DRM
implementations? I certainly think it is less efficient and not needed in some
cases, but "not possible" implies the DRM must control the channel. I think a
DRM with such a restriction would find it hard to operate as a CDM with or
without this restriction. Did you have a specific DRM in mind?

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

Received on Thursday, 21 August 2014 23:30:47 UTC