Eric Lawrence

+@nharper. I'm not opposed to removing the current same-host redirection requirement.

Neverssl made changes to their site last month that include responding over HTTPS (with a bad certificate.)

It seems like the error message should only potentially omit "It may be at risk of removal." in this scenario, but showing the other status seems fine?

> Step 5 of [Main fetch](https://fetch.spec.whatwg.org/#main-fetch) currently upgrades requests based on the [upgrade-insecure-requests](https://w3c.github.io/webappsec-upgrade-insecure-requests/#upgrade-request) mechanism. This will be replaced to upgrade navigation requests (and possibly subresources) regardless of the upgrade-insecure-requests mechanism....

Generally, disabling web security features (using the two command line arguments you've identified here) is a very dangerous configuration and is not recommended. Can you elaborate a bit more about...

>code shouldn’t be relying on the PSL or eTLD+1 In world where we're using SiteForCookies for numerous things (like SameSite cookies) and things as obscure as whether credential prompts may...

>Why would you need to, though? Well, my *personal* immediate need was responding to an enterprise who asked "Hey, we have a page at deeply.nested.fuzzle.bunnies.io and we'd like to understand...

In the ServiceWorker registration, are there any network calls to cache resources that would be returning a non-200 response, or a response with a cert error? Are there any redirects?...

Also, link rel=canonical should point to HTTPS https://docs.google.com/presentation/d/15H8Sj-Zol1tcum0CSylhmXns5r7cvNFtzYrcwAzkTjM/present?slide=id.g186a96304_0540

I remain concerned about Chrome's handling of file downloads, whereby http-sourced downloads are silently blocked, even if the target site is HSTS [1]. I was hoping that we could fix...