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

Re: HSTS Priming, continued.

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 11 Nov 2015 16:34:00 -0800
Message-ID: <CABkgnnWS3kaW_XBe6stJc65_nggDov-C4iQNNCJ6ncALO7ChSQ@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Brian Smith <brian@briansmith.org>, Crispin Cowan <crispin@microsoft.com>, Brad Hill <hillbrad@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Richard Barnes <rbarnes@mozilla.com>, Jeff Hodges <jeff.hodges@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
On 11 November 2015 at 14:50, Eric Mill <eric@konklone.com> wrote:
> Perhaps, but I'm saying it's a flatly unacceptable amount of latency in
> practice, whether or not it'd make a useful carrot.

Let's try to unpack this concern a little.  I think that there are
three classes of resource:

I think that it's obvious that if the content were active, then the
load should fail without HTTPS.  Unless you are suggesting that a fast
failure is better here(?).  I don't think that it's a deal-breaker.
We might argue that the page is busted anyway*.  [*] Caveat: that's
not true for active content that doesn't touch the rest of the
content, like tracking JS, but I can also live with less of that sort
of thing (and I'm sure DKG will agree).

If I have this right, your main concern is with the potential delay in
loading passive mixed content.  If we have to wait for a timeout
before falling back, that's pretty unpleasant.  However, I think that
at some point in the future, we may want to take that hit.  Given how
much mixed content there is at the moment, that might not be *right

I think that forcing the upgrade for the CORS preflight is a great
idea here.  Even if the content was nominally passive, the fact that
the contents of the resource will be ultimately readable by the origin
makes integrity a real concern.
Received on Thursday, 12 November 2015 00:34:28 UTC

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