[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 #54 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #50)
> 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.

Let's not broadly generalize here.

We're actually seeing more and more commercial CDNs offer high-performance,
secure, optimized TLS *for free* to their customers.

Both Amazon CloudFront and CloudFlare are two such examples.
Now, there is one particularly large CDN who continues to charge exceptionally
high rates, under the claim that it's necessary because clients do not support
TLS Server Name Indication.

I think we can assume that all such EME clients do support SNI, and we can
always normatively require such (along with TLS 1.2) within the EME spec if
there is any question or doubt about this.

As for the claims of SSL adding additional overhead or latency, I would
encourage members to read
http://tools.ietf.org/html/draft-mattsson-uta-tls-overhead-00 (for which an
update is already being prepared), that looks at the practical real-world
overhead and shows that it's virtually non-existent.

This is unquestionably a diversion from the main crux of this bug - which is
whether a secure transport MUST (normatively) be required, due to the complex
and potentially (and probable) privacy impact of EME - but if the argument is
that TLS is not viable, well, the evidence at present is that this is not the
case, and will continue to be even less of a viable argument over time.

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

Received on Thursday, 21 August 2014 21:19:20 UTC