RE: HSTS Priming, continued.

Dumb/newbie question: wouldn’t HTTPS upgrades be easy if only client browsers tried HTTPS first for every resource? Then fail back to HTTP if policy allows, or block if policy disallows mixed content.

This seems to easy. What am I missing?

From: Brad Hill [mailto:hillbrad@gmail.com]
Sent: Friday, November 6, 2015 9:55 AM
To: Mike West <mkwst@google.com>
Cc: 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>
Subject: Re: HSTS Priming, continued.

Makes sense, baby steps are good.

On Fri, Nov 6, 2015 at 9:52 AM Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
On Fri, Nov 6, 2015 at 6:40 PM, Brad Hill <hillbrad@gmail.com<mailto: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.

-mike