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>Received on Thursday, 12 November 2015 00:57:18 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC