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, 2 Feb 2015 16:47:38 +0100
Message-ID: <CAKXHy=eA8P80ErJSz5n6v-0OGktJ3Gg0PQmO20grwsMYD4MXqQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebAppSec WG <public-webappsec@w3.org>, Ryan Sleevi <sleevi@google.com>, Adam Langley <agl@google.com>
On Mon, Feb 2, 2015 at 4:39 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Equivalent, but not identical. My proposal would be to upgrade in
> Fetch similar to HSTS so that any scripts are not affected by URLs
> changing.

Hrm. So the result would be the same as a redirect? The document would have
an insecure URL, but we'd end up making a secure request?

I don't think this is a terrible idea, and it avoids some of the concerns
Adam and Ryan (CC'd. Hi Adam and Ryan!) raised in the past regarding HSTS's
request-order-dependent behavior.

That said, I'm not sure it actually solves W3C's concern, as it would leave
legacy clients out in the cold. The only way to support clients that don't
support the thing we haven't implemented yet would be to alter the links at
the source. I totally understand that that's difficult, but it seems

Having said that, I don't understand why strict mixed
> content would result in UI degradation. If we don't actually do
> something that causes harm to the user (such as fetching mixed content
> images), we shouldn't alert them about it.

We're agreeing with each other: strict mixed content checking blocks
fetches, and therefore avoids UI degradation. It also prevents the user
from being asked whether she wishes to load insecure content anyway (via
Chrome's or Firefox's shield icon), which is presented in lax mode when a
script is blocked.


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, 2 February 2015 15:48:26 UTC

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