How often are proxies set only in non-incognito by extensions?  Sounds like a niche use case to me - I assume more corporations that set mandatory proxies set them to be mandatory in incognito, too (Also...logging into what in incognito?  If you aren't using a proxy in incognito, what is there to log into?)

Punting this out of the Internals>Network queue.

> If you aren't using a proxy in incognito, what is there to log into?)

Login to the captive portal.

I don't have any data about extensions setting proxies in non-incognito, but at least BeyondCorp does it. It is niche, but currently it seems to be preventing our corp machines from detecting portals so at least it'll help with that.

Oh, right, logging into the portal.  Anyhow, unless there's evidence this is a common enterprise use case, not a fan of adding logic for it.

Bumping this out of the Certificate queue. This is about how Chrome code responds to invalid certificates, more than about suggesting we change how we validate those certificates / that we accept them.

Curious: Are proxies that support HTTPS-to-the-proxy common? I'd never seen one until joined Google. 

rsleevi:  Late response, but aren't the certificate error interstitials
(Which live in chrome/ssl, I think?) considered part of the certificate
component?

Also late response:

Comment #4: The logic for this will be in the interstitials code where we have custom logic for different scenarios including bad clock, captive portals, mitm softwares etc. The only change on the captive portal side is to pass the net error in CaptivePortalDetector::Results. Would you be okay with adding that?

UMA says that this error is pretty rare, but I suspect there is a bias there: In the cases where this error would happen (behind a captive portal), UMA wouldn't be able to report the error.

meacer@ -- Assigning this to you since you know where the fix will go, if needed.
-Enamel Sheriff

Re #c8:
> UMA wouldn't be able to report the error.
Only as long as the machine is always behind a captive portal, no?