[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 #55 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #53)
> (In reply to Joe Steele from comment #49)
> > 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. 
> 
> I think the number of sites using DRM that a user interacts with is likely
> to be small. Also, the UX issues can be mitigated. This issue is not unique
> to EME or even web APIs - native mobile apps also have per-app prompts to
> give users control.
> 
> 
> (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.

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

 Even
> reinstalling the OS (if possible) may not clear the identifier. This is much
> stronger than fingerprinting or local storage.
> 
> There are mitigations, but those are not normative either.

Well, since the whole thread is about introducing a normative requirement, we
can explore making other things normative instead. Like I've said, I don't
necessarily have a problem with saying "If conditions X, Y, Z do not hold, then
secure transport MUST be used." It's the blanket requirement I object to,
because it's unnecessary in many cases.

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

[* 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 ?]

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

Received on Thursday, 21 August 2014 21:23:28 UTC