Alignment with new DevTools Mixed Content issues

CL that creates Mixed Content issues in DevTools (not yet landed): https://chromium-review.googlesource.com/c/chromium/src/+/2116228

Our current, non-default mixed-content audit (#3953; --preset mixed-content) works like this:

• Do two passes: first is the defaultPass. The second is a special pass where we intercept http: requests and attempt to load https:. (This extra pass is why we haven’t added this audit to the default config.) For all http: requests from the defaultPass, if there was a successful load of the https: resource in the special pass the request as is deemed “upgradeable”. This means the developer can simply replace http: with https: for this request and it will work. In essence, we’re just doing this extra pass so we can be more useful in the report. (ie “The request is on HTTP, BUTTT You can just change the URL and it’ll work!” vs “the request is on http… and no idea if that resource is already available at HTTPS.”)

The Mixed Content issues created for DevTools is different. It creates an issue for all http: requests. This is similar to what is-on-https already does. Additional information included is how the request was handled by the browser (MixedContentResolutionStatus - blocked, warned, upgraded).

Proposal:

• Use phrase “Mixed Content” is-on-https audit in description
• Stronger language in https://web.dev/is-on-https/ docs re: upcoming changes to Chrome blocking content (I think images is the only remaining incoming change? https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html )
• Use the new issue event in the is-on-https audit (fallback to current impl. if not supported - drop after a few major Chrome versions)
  • New column for how the browser handled the request -MixedContentResolutionStatus

The missing ingredient for parity with LH’s non-default mixed-content is determining which blocked/warned requests could be simply switched to https:. LH does an extra pass for that (must actually attempt to load the secure request), but maybe this could be built-in to the Chrome backend? Would the increase in actionability be worth it? cc @sigurdschneider

Useful Examples:

• https://www.mixedcontentexamples.com/Test/NonSecureImage
• https://mixed.badssl.com/
• https://mixed-script.badssl.com/

[connorjclark]

Is Chrome going to issue MixedContentResolutionStatus for requests on sites that aren’t https at all? We should keep our existing validation for the completely insecure case if not.

I agree. Not sure what Chrome will do, and I can’t find a design doc, so I’m just gonna wait for it to land in Chromium rather than figure out what the CL is doing.

… any http requests will just be autoupgraded … but I suppose the argument is that the action is the same in both cases it will still be insecure on other browsers?

Good point re: Chrome. And I like the argument that followed 😃

Sounds like it would work if we framed the mixed content description for https sites 👍

Not sure what you meant here, I assume you are agreeing with the description tweak?

My personal opinion is that this is relatively low value feature for such a high cost, especially post 84 when Chrome is just going to do it for them already on the https version of the site and we can just see if it fails.

Agreed.

[connorjclark]

fixed by #10975