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/ _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
