[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 #61 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Joe Steele from comment #60)
> The key requests made by some DRMs fall exactly into this category of "very
> short connections". One packet out, one packet in. The overhead of
> negotiating an SSL channel (which may ultimately add nothing to the
> security) can be almost 100%. Even if we wait for TLS 1.3 as suggested. 

Luckily, this is not a specification that deals with legacy DRM systems that
are implemented inefficiently. Your CDM does not have a network connection
(normatively), it defers to the UA to mediate all key exchanges.

It's amazing how exceedingly efficient UAs are. TLS session resumption.
Connection pools. HTTP keep-alive. Novel technologies like XMLHttpRequest or
WebSockets. All of these exist, and despite your "key exchange" or "drm"
protocol being "one packet in, one packet out", it's nearly virtually
impossible to actually find yourself establishing a new connection every time,
or dealing with that overhead.

Equally, I think you'll be hard pressed to find a single EME/CDM implementation
that's sending as many packets of video stream data as they're receiving, so
you surely cannot mean that.

So, especially as demonstrated by browsers (and the updated version includes
even more real world data from a variety of high-capacity sites), your overhead
is virtually nil.

Also, I think the concerns about latency are a bit misinformed. Latency matters
every bit as much for websites serving content as they do video providers.
Milliseconds of latency are measured in impacts of millions of dollars. Seconds
of latency are measured in billions. If the latency impact from SSL has not
shown to be crippling online commerce, I think you can rest assured it won't
compromise streaming either.

http://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales

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

Received on Thursday, 21 August 2014 22:38:28 UTC