Wait for the insecure content page and show an error.

[Janpot]

There was also a potential race condition with listening to the load event.
I fixed this by moving the call to _waitForLoadEvent before the call to
Page.navigate.

[Janpot]

Still work in progress but for feedback

[paulirish]

Nice. Do you want to add a smoketest for this that checks one of the badssl domains?

[brendankenny]

This currently halts the trace (pass stage) and moves on to the afterPass stage of the gatherers when an insecure state is found. Don't we want to stop the lighthouse run altogether because it's not actually measuring the target page, it's measuring the "Your connection is not private" page?

[Janpot]

@paulirish Will look into the smoketests.

@brendankenny What do you suggest? I can reject when there is insecure state. I think that stops the whole process and shows a Runtime error. Also, keep in mind that some passes actually work when reviewing https://www.cnn.com.

[brendankenny]

@brendankenny What do you suggest?

I mean, it is a pretty big error, so I think it should probably reject altogether. The gatherer results will be at best inconsistent, with many of the results (e.g. performance metrics) actually for the "Your connection is not private" page and not the target page, with only a log entry to tell the difference.

Sort of related: are there other cases besides the "Your connection is not private" page interstitial page that are treated as securityState insecure? #1123 (comment) makes it sound like there's no explicit test, and we don't want to conflate different cases. OTOH, if Chrome always refuses to show a page when insecure the distinction might not matter.

[Janpot]

Another option would be to start Chrome with the --ignore-certificate-errors. In my project that makes sense as auditing security is part of our reports.

[paulirish]

Another option would be to start Chrome with the --ignore-certificate-errors.

heh. That was our resolution last time we discussed this: #559

[Janpot]

That wouldn't work at all together with this PR though, the navigation wouldn't wait for the load event anymore. Personally I think the --ignore-certificate-errors makes most sense if there's an audit for the security issue.

[brendankenny]

@Janpot so where you think this should go?

Direct users to --ignore-certificate-errors and add an audit for insecure security state? Looks like crbug.com/504499 will also (eventually) give us a debugger protocol method of detecting the SSL interstitials directly

[Janpot]

@brendankenny Maybe as additionalFlags here?

[Janpot]

@paulirish @brendankenny Ok, gave it a bit more thought. I think the right way to go for now would be to direct users to --ignore-certificate-errors. Closing this PR since it would break that workflow. As far as I can see there is no way to properly detect this failure.
It seems like a Network.loadingFailed event is not coming through when chrome blocks on insecure state.