Re: Fetch, MSE, and MIX

On Fri, Mar 6, 2015 at 2:43 PM, Mark Watson <watsonm@netflix.com> wrote:

> Ryan,
>
> Proposals like this might allow video-intensive sites to migrate to HTTPS
> sooner than otherwise and are thus very welcome. This one was originally
> suggested by Anne Van Kesteren, I believe. Or at least something very
> similar. However, this particular proposal suffers (IIUC) from the
> disadvantage that users are likely to be presented with mixed content
> warnings. That's not an acceptable user experience for a professional
> commercial service.
>

Well, it's an accurate presentation of the security state of said
commercial service.

That is, it is actively disclosing your activities to anyone on the
network, for any number of purposes - profiling, tracking, analysis, etc. I
wish we could say these were purely the result of paranoia or theoretical
concerns, but we have ample evidence that they are real, practical, and
concerning. Given how many professional commercial services' offerings (at
least in the context of MSE) are often in business competition with the
transit providers, I do find it somewhat surprising that this is seen as a
desirable state - that is, where the commercial services disclose their
users' viewing habits, preferences, and profiles to those who would most
benefit from the competitive insight. But I digress...


> I understand the reasons that mixed content warnings are presented: the
> properties of the HTTP media requests do not align with the user
> expectation of privacy and security which is set by the presence of the
> "green padlock" or other UI indications of secure transport. A viable
> interim solution - without such warnings - either needs to avoid setting
> this expectation or to include additional measures such that the warnings
> were not necessary. If the latter, we'd need to evaluate whether such
> measures were worthwhile as an interim step or whether the investment would
> be better spent on the move to HTTPS proper.
>

Well, it's between unwise to impossible to meaningfully address the privacy
concerns, even if you were to attempt to address the security concerns.
That is, you're still disclosing activity to the network observer, and that
fundamentally undermines the confidentiality goal of HTTPS.

As it stands, the current design of MSE (and, therefore, EME, as some EME
implementations require MSE) incentivizes media sites towards HTTP as the
path of least resistance / least UI. However, in doing so, it also leaves
users open to serious privacy and security risks, both in the local level
(EME) but also at the overall platform level (cookies, local storage, etc).

It's also worth considering how proposals like [1][2] will affect the
overall UI state, such that HTTP would appear, to the user, worse than
mixed content (as the active injection of arbitrary code is far worse than
the tracking disclosure). Or to consider how deprecation plans for powerful
features, such as those in [3][4], might see the usage of features (such as
EME) over HTTP be presented with access permissions or negative UI.

In this world in which the platform reasonably and rightfully is moving
away from HTTP - both for powerful features (as per [3]/[4]), but also as
the "Everything is fine, nothing to worry about" state (as per [1]/[2]) -
whether this provides a meaningful interim step between the "Actively
insecure" and "Meaningfully secured from network attacks" status.

[1]
http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
[2] https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0062.html
[3] https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0431.html
[4]
https://groups.google.com/a/chromium.org/d/topic/blink-dev/2LXKVWYkOus/discussion