[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 #75 from Joe Steele <steele@adobe.com> ---
(In reply to Henri Sivonen from comment #70)
> (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%.
> 
> Not necessarily if the key requests get multiplexed into a pre-existing
> SPDY/HTTP2 connection that's open to the server where either the HTML page
> already came from, which is quite possible when the key requests go over XHR
> and go to an application server in front of the actual key server so that
> the application server can check cookies.

Most small to medium size content publishing companies do not want the hassle
of running their own license servers (especially multiple of them). They will
either choose to use services provided directly by the DRM vendor or those of
an OVP like Brightcove who provide all the endpoints. In the either case, the
license server is not likely to be running on the same server the application
is being served from. However the large companies who run their own license
servers are also the ones who would most benefit from this optimization. It
would be good to have feedback from big content publishers (e.g. Youtube,
Amazon, Comcast to name a few).


(In reply to Ryan Sleevi from comment #68)
> (In reply to Joe Steele from comment #64)
> > None of this efficiency makes any difference in this case. The CDM is
> > constructing the request - which in our case is a single packet. The
> > application can use any mechanism to send it it likes, but HTTP is good
> > enough in our case and quite efficient. TLS would be overkill and not add
> > anything to the security. 
> 
> You cannot have your cake and eat it to. You just described the overhead as
> being one packet in, one packet out, but that's clearly not the case. Just
> because the CDM constructs the request does not require, as you incorrectly
> suggested, that a UA establish a new connection.
> 
> Note that you're also firm in the territory of non-guaranteed behaviour when
> you say "HTTP is good enough in our case". One, UAs can and will disagree
> with that assertion for *your* protocol, and two, not all CDMs may be able
> to implement that.
> 
> In the absence of hard guarantees about the security properties, requiring
> TLS is to ensure that even at a baseline, the security properties are the
> minimal acceptable level, and in a way that's consistently implemented
> (ergo, interorperable)

I think it's fairly clear at this point that we are not going to convince each
other. However I am willing to stipulate that requiring openssl for the
application download would be really good thing. I am also willing to stipulate
that requiring it for the key exchange is not a bad thing. It may not add
anything to privacy in some cases, but if it makes the APIs more palatable I am
not opposed. I am not convinced that requiring it for the media APIs is a good
idea - which is what this will effectively do as far as I can tell. 

We have one large content publisher commenting that this will be a problem. We
need more feedback from others content publishers. 

Ryan/David can you reach out for comment to the folks who work on YouTube and
get their feedback here? 

Anticipating that the rest of the feedback from content publishers will be
negative, is there any way we can mitigate the mixed-content problem?

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

Received on Monday, 25 August 2014 16:03:04 UTC