On Wed, Nov 11, 2015 at 4:44 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:
> 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"
>
Perhaps, but I'm saying it's a flatly unacceptable amount of latency in
practice, whether or not it'd make a useful carrot.
In my personal internet journey, I test out adding an "s" to "http://" a
*lot*, to see whether content is available over an HTTPS connection. When
content is not available over HTTPS, it doesn't just immediately stop. The
connection can hang for many seconds before whatever relevant client- or
server-level timeout is triggered.
-- Eric
>
> --dkg
>
--
konklone.com | @konklone <https://twitter.com/konklone>