- 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>
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
faster"
--dkg
Received on Wednesday, 11 November 2015 22:45:32 UTC