Re: [EME] Mitigating the impact of HTTPS on content providers

There is a proposal for a solution [1] to enable MSE buffers to be treated
as Optionally-blockable Content in Mixed Content scenarios in the same way
as standard src= sources. It would solve the general inconsistency between
these two types of sources of media data and removes one hurdle for
MSE-using sites to switch their pages, cookies, etc. to HTTPS. It also
addresses the short term impact to MSE-using content providers of requiring
secure origins to use the EME APIs [3].

For EME, the proposal has the same effect as idea #2 below but is much more
natural and does not requires any EME-specific changes. Note that it
involves Fetch instead of XHR

Feedback on the proposal has been minimal, mainly related to the details of
cookies, whether it weakens web platform security, and whether it would
address the EME issue. I expect that details will be worked out as the
proposal is formalized. If you have comments on the proposal, please reply
to the cross-posted proposal thread [1].

Since the blocking of HTTP requests for MSE was the main objection to
requiring secure origins for EME [3], I believe this gives us a path
forward on resolving that bug. This unblocks the completion of the
“powerful features” (formerly secure origin) algorithm step [4], but we
will need to decide how to document the relationship to the availability of
the Fetch and MSE functionality along with a maximum date for HTTP support.
That date would be similar to the flag day previously discussed but would
hopefully not impact user agents that implement the proposal [1], allowing
sites to switch to HTTPS sooner.

[1] https://lists.w3.org/Archives/Public/public-html-media/2015Feb/0038.html
[2] http://www.w3.org/TR/mixed-content/#category-optionally-blockable
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
[4] https://w3c.github.io/encrypted-media/#requestMediaKeySystemAccess


On Fri, Oct 24, 2014 at 9:53 AM, David Dorwin <ddorwin@google.com> wrote:

> The main objection to requiring secure origins for some or all key systems
> seems to be the impact this would have on content providers using MSE -
> mixed content restrictions would require them to also serve the encrypted
> media streams from a secure origin. While there is still some debate as to
> the actual impact, I'd like to start a brainstorm and discussion of ideas
> on how we might reduce the (immediate) impact on content providers while
> enabling user agents to require secure origins (in a reasonable timeframe).
>
> Here are some ideas to start the brainstorming. (I don't necessarily
> support any of them at this point.)
>
>    1. Define a flag day by which HTTPS must be supported/required.
>       1. See http://lists.w3.org/Archives/Public/www-tag/2014Oct/0100.html
>       .
>       2. There might be some sort of timeline / phased-in transition.
>          1. For example, ramping up the amount of HTTPS traffic.
>       2. Temporarily allow Mixed Content XHRs to be provided to MSE when
>    EME is in use.
>       1. Non-secure XHR responses passed to MSE would temporarily be
>       considered Optionally-blockable Content like normal video.src content.
>       2. Given a choice, securing EME is probably more important than
>       preventing use of mixed content with MSE. (The alternative seems to be that
>       none of the bytes are secure.)
>       3. We would need to consider the security implications.
>       4. This exception would be eventually be phased out as in #1.
>       5. I'm not sure how practical this would be for implementions.
>    3. Establish an informal flag day, such as an agreement among major
>    browser vendors and/or content providers.
>       1. The goal would be to prevent content providers from segmenting
>       the platform by refusing to support user agents that choose to require
>       HTTPS. (See the second to last paragraph in
>       http://lists.w3.org/Archives/Public/www-tag/2014Oct/0096.html.)
>
>
> David
>