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

On Fri, Oct 24, 2014 at 3:37 PM, Jerry Smith (WINDOWS) <
jdsmith@microsoft.com> wrote:

>  We believe that Intranets should not be mandated to run https.  Perhaps
> we should consider an exclusion for it.
>

The current text uses authenticated origin
<http://www.w3.org/TR/mixed-content/#authenticated-origin>. I believe
Intranets would fall under private origin
<http://www.w3.org/TR/mixed-content/#private-origin>. We can discuss the
risks with experts in this area.

>
>
> Implicit in temporarily allowing mixed MSE content Is an assumption that
> performance concerns (raised previously) can be resolved and the temporary
> exception can expire.  Is there a rationale that suggests the performance
> issues will be overcome anytime soon?
>

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c88, Mark said:

> Suffice to say, for the moment, that the costs associated with simply enabling HTTPS are very significant. A managed migration, at a reasonable pace with time for software and hardware optimizations to be developed and deployed, has a different, lower, cost.
>
> That seems to imply that even his performance concerns can be addressed.


>
>
> Jerry
>
>
>
> *From:* David Dorwin [mailto:ddorwin@google.com]
> *Sent:* Friday, October 24, 2014 9:54 AM
> *To:* public-html-media@w3.org
> *Subject:* [EME] Mitigating the impact of HTTPS on content providers
>
>
>
> 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.
>
>
>    1. 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.
>
>
>    1. 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
>