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

Re: HSTS Priming, continued.

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 11 Nov 2015 17:44:31 -0500
To: Eric Mill <eric@konklone.com>, Brian Smith <brian@briansmith.org>
Cc: 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>
Message-ID: <878u64p35c.fsf@alice.fifthhorseman.net>
On Wed 2015-11-11 15:09:49 -0500, Eric Mill wrote:
> I think that would introduce what are likely unacceptable latency times for
> img, audio, and video contents that are not available over HTTPS but would
> otherwise be immediately loaded/allowed over HTTP.

To be clear: you're saying it's extra latency because in the simpler
solution there is no HSTS cache to store a "do not upgrade" value across
a given subresource origin, right?  Whereas with HSTS Priming, you could
cache both negative and positive results, which means that subsequent
requests for subresources from the same origin would load faster.

To me, this sounds like another argument in favor of the simpler
solution (and against priming).

In particular, I think it's a feature, not a bug, to introduce
additional latency for cleartext traffic.  I'd love to be able to say to
a server operator "you should offer your site under HTTPS, it will be

Received on Wednesday, 11 November 2015 22:45:32 UTC

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