Re: HSTS Priming, continued.

On Wed, Nov 11, 2015 at 6:46 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> I agree with Martin that for content that would otherwise be blocked, we
> don't care about the latency.
>

It'd definitely be a lot less important, but you still might -- user
perception/reaction to a website that's "still loading" for a long time
might be worse than to a website that quickly blocked active content and
visibly completed the loading process.

Not trying to be contrarian -- security is more important than latency in
the abstract -- just trying to be complete about the tradeoffs.

On Wed 2015-11-11 19:34:00 -0500, Martin Thomson wrote:
> > If I have this right, your main concern is with the potential delay in
> > loading passive mixed content.  If we have to wait for a timeout
> > before falling back, that's pretty unpleasant.  However, I think that
> > at some point in the future, we may want to take that hit.  Given how
> > much mixed content there is at the moment, that might not be *right
> > now*.
>
> Alternately, browsers adopting this strategy where UA policy allows a
> fail-through to cleartext (because "passive" content) could just use a
> shorter timeout than normal before triggering a fail-through, right?
>
> One concern here is that this might touch too many layers to be
> feasible, since timeouts might be in any or all of TCP session
> establishment, TLS handshake, HTTP response.


> But the browser could presumably just set a timer and say "if this
> request isn't back and done in K milliseconds, we're going to abort it
> and kick off an http request".
>

Yes, and to be clear, these latency issues are still there for HSTS
priming. I don't see a reference to timeout policy in the HSTS priming
spec, but a UA would have to decide on an acceptable client-side timeout
either way before proceeding. So that logic will have to be written either
way.

HSTS priming mitigates the impact of the timeout process more effectively
because of its cache (of both positive and negative responses).

-- Eric


>
>     --dkg
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>