Re: Fetch, MSE, and MIX

On Fri, Mar 6, 2015 at 3:00 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
> 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 didn't say the mixed content warnings were not accurate and I didn't say
that disclosing viewing habits was desirable.​


>
>
>> 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).
> ​
>

​I would dispute that EME per se necessarily opens users to serious privacy
and security risks. If done wrong, sure, but this is true of anything. I'm
hopeful that UA vendors will provide EME solutions that are relatively
benign in this respect and I know a number who are trying very hard to do
so.
​​

>
> 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.
>

​All very worthy of consideration, as you say. Again, if browsers do
provide a viable interim step, that could get sites improved security
sooner than they otherwise would.

…Mark



>
> [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
>
>