I'm less concerned about non-secure script in an otherwise-secure page, because good UAs block it outright anyway. Point your favorite browser at https://mixed-script.badssl.com/, for example. Desktop Firefox and Chrome refuse to load the non-secure script, but have an option to let the person load it anyway (with suitably frightening messaging); Safari and Chrome for iOS, and it seems Safari for desktop, don't even have that option. IE makes it a bit too easy to load the non-secure script for my tastes, but even so it's safe by default. And most browsers do still distinguish fully-secure page-loads from those that have some mixed display content. So, assuming a good UA, UIR-FB seems to be much more of a win for HTTPS deployment than a safety risk. My boundless optimism ;) allows me to hope that the slowness of the 2 round-trips (as Tanvi mentioned) would be incentive enough for some/many/most site operators to use UIR-FB only as a temporary aid and not a permanent mode of deployment. Surely, some will leave it permanent, so we'd still have to do all the usual outreach and evangelism. I don't relish latency, evangelism, or complexity, but I don't see that UIR-FB creates a new vulnerability, and the benefits could be substantial.
Received on Friday, 1 July 2016 19:00:03 UTC