[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 #59 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #57)
> (In reply to Mark Watson from comment #55)
> > (In reply to David Dorwin from comment #53)
> > > (In reply to Mark Watson from comment #50)
> > > > 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.

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.

> 
> > > > 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.

That doesn't really answer my point.

It's being argued here that migration to HTTPS is trivial, low cost, and
therefore a reasonable thing to expect people to do when migrating from
plug-ins to EME, even though the technical rationale is weak / restricted to
CDMs that do not follow the privacy / security mitigations in the document (but
nevertheless somehow get themselves integrated into a UA).

I'm disputing both that it is low-cost, particularly at scale, and that the
mitigations in the document are insufficient.

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

Received on Thursday, 21 August 2014 22:18:56 UTC