[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 #57 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #55)
> (In reply to David Dorwin from comment #53)
> > (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.
> 
> That's fine if the UA implementor and CDM vendor are distinct or not
> communicating with each other. But in the case that they are the same
> entity, or where the UA implementor feels they have been told enough about
> the CDM's operation, it's unnecessary to use a secure transport.

Maybe, but are Netflix and other content providers going to offer HTTPS support
for those UAs that feel secure transport is necessary? If not, the point above
is moot because that would segment the web platform in an unacceptable way.

> > > 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.
> 
> I qualified my statement with a restriction to those DRMs that *don't* do
> that: Those that enable users to clear the identifier as per the privacy
> mitigations.
> 
> Those mitigations need to be in place because secure origins don't help with
> those attacks.

Both #5 and #6 include "an active attacker on the network". Secure origins
absolutely help with those attacks.

> > > 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.
> 
> Sure. If all video traffic on the net migrates to HTTPS then there is
> probably also a market opportunity for optimized NICs*, solutions to
> operational problems, further optimizations to TLS speed, opportunities to
> short transparent proxy providers and to poach customers from ISPs who use
> them (whose networks are now toast). But you are talking about a five-year
> project here whilst proposing to enforce the requirement right now.

As the geolocation API has shown, we only get one chance to get it right.
> 
> [* https://istlsfastyet.com/ says 'Good news is, modern hardware has made
> great improvements to help minimize these costs, and what once may have
> required additional hardware can now be done efficiently by the CPU.', but
> what if your data is not flowing through a CPU at the server ?]

See Ryan's comment #54.

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

Received on Thursday, 21 August 2014 22:05:13 UTC