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

Re: HSTS Priming, continued.

From: Richard Barnes <rbarnes@mozilla.com>
Date: Wed, 11 Nov 2015 19:09:03 -0500
Message-ID: <CAOAcki9JSBVL3u5s_-MgEdmB1mZbGwgnYa6YE52At24kzfq=PQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <jeff.hodges@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Adam Langley <agl@google.com>
Catching up on this thread...

On Fri, Nov 6, 2015 at 12:52 PM, Mike West <mkwst@google.com> wrote:

> On Fri, Nov 6, 2015 at 6:40 PM, Brad Hill <hillbrad@gmail.com> wrote:
>> I like it.  Even if you don't want to apply it normatively to
>> navigational requests, it might be useful to suggest that the prefetcher,
>> if one exists, should perform priming.
> Sounds reasonable:
> https://github.com/mikewest/hsts-priming/commit/75877a33528c0c3893d599dd5c26864db4538313
> That said, the concerns I've heard from folks to whom I've shopped this
> proposal have centered around load (especially in geographic regions that
> blackhole requests to port 443 in a way that fails slowly rather than
> quickly). I'd like to start with something small that won't have a
> seriously detrimental impact on load times.
> Also, selfishly, it's a lot easier to poke at subresource requests in
> Blink, as we can reuse much of the infrastructure that CORS preflights have
> paved. Navigations are harder, especially as the implementation is a bit in
> flux at the moment.

I would be fine scoping this to subresources to start with, since the major
point is to avoid mixed content issues. And since HSTS gets cached, doing
priming for subresources will help indirectly with navigations.


> -mike
Received on Thursday, 12 November 2015 00:09:33 UTC

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