[webkit-dev] Mixed content checking

[Michael Catanzaro]

Hi Alexey,

On Wed, 2014-07-23 at 22:59 -0700, Alexey Proskuryakov wrote:
> Thank you for the heads up!
> 
> Can you elaborate on why this is desirable? A non-https frame always
> has a different origin, so it can't script the main frame.
> 
> In other words, how is "active content" defined here?

One big reason is that if an insecure frame is loaded on an HTTPS page,
users may believe the page to be secure even though a substantial
portion of that page may not be; browsers generally display a warning
icon when a page display mixed content, but users generally ignore it.
This used to be a big problem, but nowadays no major browser except
Safari allows mixed content frames [1], so it's a low-risk catch-up for
us.

[2] describes a couple other good reasons for blocking these frames
(scroll down to "mixed content frames"). Please note that when [2] was
authored only IE and Firefox were blocking mixed content frames, but
Chrome started doing so some months ago.

> Same question, why? Cross origin XMLHttpRequest is different from
> cross origin scripts in that it takes quite a bit of effort to make it
> work, so it's not the same case of accidentally loading a subresource
> using http instead of https.

Even so, no major browser besides Safari currently allows mixed content
XMLHttpRequests, so I think this is a low-risk restriction. (Again see
[1], but note that Chrome has quite recently begun blocking these as
well.)

Happy Thursday,

Michael

[1]
https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl
[2]
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/