[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 #123 from Henri Sivonen <hsivonen@hsivonen.fi> ---
Ryan has been provoking me on Twitter about this topic. He wins in the sense of
succeeding at getting me to say more here.

First of all, as has been pointed out in the www-tag thread, if one vendor
restricts EME to https and others don't, the vendor who restricts EME to https
is at a considerable competitive disadvantage when it comes to compatibility
with video services, which means that requiring https conditionally depending
on the characteristics of the key system or the CDM it's not a solution that's
actually going to work.

Mozilla has been down the road of putting the righteous aspirations shared by
Google to practice while Google allowed them to remain mere aspirations and
attempts to "signal" to the industry
(http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html).
While Google has been "signaling", Chrome has been enjoying the compatibility
benefits of supporting H.264 and Firefox has lost users to Chrome.

With that background, I hope it's understandable that I'm not jumping at the
opportunity to make Firefox ship with EME restricted to https, when Chrome, IE
and Safari are shipping (some prefix snapshot of) EME without such a
restriction and would enjoy the competitive compatibility benefits if Firefox
made it harder for sites to become compatible with Firefox+Access. (It's tough
enough that EME-style DRM involves the sites having to operate a different key
server for each browser when each browser is associated with a different key
system.)

I'm sure that despite tweets like
https://twitter.com/sleevi_/status/526783956264316928 Ryan is well familiar
with the dynamics described at
https://freedom-to-tinker.com/blog/jbonneau/poodle-and-the-fundamental-market-failure-of-browser-security/
. If the conflict between compatibility and security was not real, browsers,
Chrome included, would have disabled SSLv3 proactively without having to wait
for POODLE to give a push to merely express hope to do so. Whereas SSLv3 may be
a long-tail issue (and *still* didn't get proactively disabled), EME has
relevant to popular services, so the situation is even worse than with SSLv3.

If the idea is to just get me to say that https-only is the righteous *goal*
but no one is actually expected to ship a browser that way in the near term, as
https://twitter.com/sleevi_/status/527007790150070272 suggests, I think it's a
problem to pat ourselves on the back for signaling an https-only future when
not actually addressing the privacy problems in the http-allowing reality that
everyone is going to ship.

Since I care about the privacy properties of EME in general and EME-in-Firefox
in particular and I expect Chrome, IE and Safari to keep shipping without an
https-only restriction, I think it's not good enough to to say that the spec
restricting things to https only mitigates the privacy problems if https-only
isn't actually what gets shipped. This is why I'm interested in finding ways to
address the privacy issues without https, even though in principle, it's not
cool to try engineer for https avoidance and it's not good to be seen as trying
to engineer for https avoidance. I then want to (try to at least) push those
mitigations to be real in what Mozilla ships. I also hope that documenting
solutions that don't require https in the spec helps improve the situation for
users of other browsers, too.

Is worth noting that restricting EME to https origins is not a silver bullet.
In particular, it doesn't address privacy problems related to what the site at
the other end of the TLS pipe learns. That is, mandating https does not remove
all the problems that affect permanent Web-exposed unique identifier poses.

Also, restricting EME to https origins the way Chrome has restricted Web Crypto
to https origins—i.e. requiring the origin that calls the API to be an https
origin—is not good enough to address the concerns that Ryan raises in
https://twitter.com/sleevi_/status/526586427656507394 and in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c114 . The MITM would
inject an https iframe into http pages such that the https iframe loads from a
MITM-controlled server that has a legitimately obtained certificate and serves
a JS app to talk with a MITM-controlled key server that sees the identifier
exposed by the key system. To make the DRM identifiers unavailable to an active
MITM (unless the MITM forges certificates), the https-only restriction must
apply to all origins in the whole chain of browsing context from the browsing
context using EME to the top-level browsing context. In other words,
https://dvcs.w3.org/hg/html-media/rev/896eb33b68a2 does not actually address
the threats that Ryan has brought forward.

On the other hand, if the spec required the sort of identifier and associated
storage partitioning that Mozilla is on track implementing, i.e. partitioning
by all of:
 1) Device-unique bits.
 2) The origin using EME.
 3) The origin of the top-level browsing context.
 4) A randomly-generated salt associated with the pair of #2 and #3
and persisted until the user requests the salt be forgotten.)
...node locking would still be accomplished thanks to #1, but tracking across
sites would be prevented and the user would have the opportunity to cause a
discontinuity in tracking on a particular site.

If the spec further required the key system to encrypt messages such that the
identifier is only visible to the key server, in terms of the id exposure, the
result would be close (equivalent even?) to the https case (as currently
written without the requirement for the whole browsing context path to the
top-level to be https-only) as far as the threat of a key server-operating
active MITM who injects EME-using iframes that connect to the MITM-operated key
server goes.

Still, this leaves the question of what to do about such a MITM being able to
surveil the user over time by always injecting the EME usage to a particular
(so as not to be tripped up by the partitioning by the origin of the top-level
browsing context) commonly-accessed http site (perhaps to reassociate dynamic
IP numbers with a persistent identity). As far as I can tell, this could be
addressed by partitioning the identity on the temporal axis automatically
instead of only when the user requests the salt to be forgotten. This should be
logically possible to the extent EME is used for streaming and for short-term
off-line-rental implemented using licenses valid for the rental period and
media data cached by a Service Worker.

What problems (besides the overhead of reinvidualization) do DRM vendors and
service operators see with automatic temporal partitioning of the CDM identity?

The obvious problem I see with the efficacy of this kind of solution is that if
the CDM identity renews automatically from time to time but the browser doesn't
drop all site-specific data at the same time (and doing so automatically would
be impractical), various client-side storage mechanisms could be used to
correlate the old and new CDM identities in a manner analogous to cookie
resurrection.

P.S. Regarding cookie equivalence: If cookies were designed today, they'd be at
minimum origin-scoped and possible https-only. Arguing mere cookie equilavence
risks falling into the pattern that DJB characterizes as arguing against
encrypting SNI because DNS traffic is unencrypted and arguing against
encrypting DNS traffic because SNI is unencrypted.

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

Received on Wednesday, 29 October 2014 13:50:12 UTC