W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: Upgrade mixed content URLs through HTTP header

From: Mike West <mkwst@google.com>
Date: Mon, 9 Feb 2015 09:37:43 +0100
Message-ID: <CAKXHy=cJ1Q436u=NBe3GD30c_8C96FscYW8cw93HQooB0AsFpw@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: John Wong <gokoproject@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Alex Russell <slightlyoff@google.com>, Joel Weinberger <jww@google.com>, Emily Stark <estark@google.com>, Jim Manico <jim.manico@owasp.org>, Ryan Sleevi <sleevi@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
Hey Tanvi!

On Fri, Feb 6, 2015 at 8:27 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:

> * Option 1 - Fallback and try the HTTP version; the mixed content blocker
> will be invoked and the content will be blocked if it is blockable with an
> option for the user to override the blocking (shield shows up in Firefox
> and Chrome) or loaded if it is optionally blockable with a degraded
> security UI.
> * Option 2 - No attempt to access the HTTP version and no mixed content UI.
> Option 2 will result in a user experience that is worse than the current
> experience with mixed content blocking.  Also, with Option 2, sites may be
> less likely to set the CSP directive because it could potentially break
> their site. Hence, I like Option 1 where we fallback to the HTTP version.
> But this could cause performance issues since in the fallback case we are
> doing two resource loads instead of one.

The strawman I posted is option #2; resources are upgraded, and if the
upgrade fails to target a viable resource, you'll end up with a network
error, just as you would if you typed the upgraded URL manually.

The intention is that only sites for which this behavior provides a net
gain will opt-into it. So, while I agree that there's some risk, it can be
a calculated one which sites can choose to opt-into.

> We could also have Option 3 - only fallback for optionally blockable
> subresources, since many users don't click the shield and override
> protection anyway and hence end up with a similar user experience.

This is probably worth experimenting with today, especially in combination
with HSTS. I worry that it's likely to have negative performance impact on
sites, as it would no longer be opt-in, meaning that sites that wouldn't
support upgrade for particular resources would be generating unexpected
requests that they weren't prepared to handle.


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 9 February 2015 08:38:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC