[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 #66 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #65)
> (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?

See the mitigations in comment #52. Note that I said *implementations*, not
systems or protocols. It's certainly possible to add such mitigations to an
implementation, but it might require platform upgrades in some cases. If that
is required, there are a lot of other interoperability issues that can also be
addressed.

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

Received on Friday, 22 August 2014 00:53:24 UTC