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

I'm finding Brad's arguments pretty convincing.  UIR-FB verges on being
harmful for pages that are "https:" at the top level, since it encourages
half-baked deployment.  There could be some benefit for pages that are
"http:" at the top level, but that's not really a population that I'm
interested in investing in right now.

Net of all that, I would be comfortable letting this proposal drop.

On Fri, Jul 1, 2016 at 3:41 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I agree it creates no new vulnerabilities, but I question the benefits.
>
> Yes, user agents do and will continue to block insecure scripts.  This is
> exactly the crux. If you got a new cert for your http site that depends on
> external scripts to render important user experiences, make buttons click,
> or just measure the ads that pay to keep you in business, you can't start
> sending users to the https version yet if those scripts don't upgrade.
> This is why I think that it's not realistic to think that Certbot could
> just start flipping the switch automatically.  Modern web apps depend
> deeply on scripts and things will break.
>
> Certainly there is some population of sites that could benefit from
> UIR-FB.  If the cost to implement is very cheap, let's do it.  If it's not,
> we should try to understand a bit how big that population is.
>
> On Fri, Jul 1, 2016 at 11:59 AM Chris Palmer <palmer@google.com> wrote:
>
>> 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.
>>
>