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

This is a good direction to take the discussion, but I'd like to see the
pre-emptive change under bug 26332 reverted first.

...Mark

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
>