1313597 - HSTS priming requests should show up in the developer console

Status: RESOLVED INVALID

(Core :: DOM: Security, defect, P3)

Description

[Kate McKinley [:kmckinley, :Kate]]

HSTS priming requests should show up in the network panel of the developer console and be clearly marked as such.

Comment 1

[Honza Bambas (:mayhemer)]

The simplest way is to add them to the document's load group, which may be something we should do anyway.

Do you thing it's time thinking about coalescing the requests?  (that would complicate adding it to a load group).

Comment 2

[Kate McKinley [:kmckinley, :Kate]]

(In reply to Honza Bambas (:mayhemer) from comment #1)
> The simplest way is to add them to the document's load group, which may be
> something we should do anyway.

After taking a quick look at this, I am running into a similar block to the UI, which is that the load group appears to live in the child process, but the priming request is kicked off in the parent, and the load group isn't passed to to the parent. Do you have any thoughts on this? In non-e10s mode the load group seems to be added appropriately by NS_NewChannelInternal.

> Do you thing it's time thinking about coalescing the requests?  (that would
> complicate adding it to a load group).

It might be a good time to do this, what do you think?

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Kate McKinley [:kmckinley] from comment #2)
> (In reply to Honza Bambas (:mayhemer) from comment #1)
> > The simplest way is to add them to the document's load group, which may be
> > something we should do anyway.
> 
> After taking a quick look at this, I am running into a similar block to the
> UI, which is that the load group appears to live in the child process, but
> the priming request is kicked off in the parent, and the load group isn't
> passed to to the parent.

Oh.. yes, I forgot about this :(

> Do you have any thoughts on this? 

except starting the priming request on the child process (which is probably going to be hard), nothing really simple.  sending down to the child some IPC message to create a "fake" channel on the child and add it to the "right" load group seems to me really an overkill.  currently we don't have a way to start http channels from the parent process and be carried down to the child process.  but maybe it's time to introduce some .. let me think a bit more about this.


>In non-e10s mode
> the load group seems to be added appropriately by NS_NewChannelInternal.
> 
> > Do you thing it's time thinking about coalescing the requests?  (that would
> > complicate adding it to a load group).
> 
> It might be a good time to do this, what do you think?

Hm... depends if the devtools thing and coalescing would be related code changes, then yes.  otherwise I would bother only in case we find out non-coalescing being a real performance issue.  It could if you opened multiple same origin pages that didn't have HSTS state cached.

Comment 4

[Kate McKinley [:kmckinley, :Kate]]

(In reply to Honza Bambas (:mayhemer) from comment #3)

> > > Do you thing it's time thinking about coalescing the requests?  (that would
> > > complicate adding it to a load group).
> > 
> > It might be a good time to do this, what do you think?
> 
> Hm... depends if the devtools thing and coalescing would be related code
> changes, then yes.  otherwise I would bother only in case we find out
> non-coalescing being a real performance issue.  It could if you opened
> multiple same origin pages that didn't have HSTS state cached.

In a simple test with my timeout test case hosted on a domain I own, loading the same origin which primes an origin which times out, the two pages timed out about the same time, even if I start one well after the other, so it looks as though some of this might be done already. I don't have a good way to write a test which times out because it needs a firewall which drops packets instead of rejecting.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

HSTS Priming code was removed a long time ago - closing this bug.