Re: [UPGRADE] upgrade-insecure-request-with-fallback

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