Of course that would be a problem, but that simply isn't the case. It certainly wasn't the case for Portal or any other site I've seen that used this feature. L

Of course that would be a problem, but that simply isn't the case. It certainly wasn't the case for Portal or any other site I've seen that used this feature. Limiting this to only secure contexts would solve your problem and is what Google is technically doing. The issue is that requests from HTTPS->HTTP sites in aren't allowed either ("Mixed Content") and so effectively, Chrome is disallowing ALL public->local requests, since HTTPS on a local site is broken by design. > If your website needs to issue requests to a target server on a private IP address, then simply upgrading the initiator website to HTTPS does not work. Mixed Content prevents secure contexts from making requests over plaintext HTTP, so the newly-secured website will still find itself unable to make the requests. The solution, of course, is clear to the Chrome devs - certificate pinning. Unfortunately, they implemented it in an absolutely ridiculous way that limits you to WebTransport for absolutely no other reason other than they want to force developers to use it as soon as possible before the other browser vendors (*vendor) implement it. As I mentioned in a sibling comment, there is absolutely no reason to not simply add a "CACert" option to XHR,fetch,WebSocket... and let developers use the existing protocols.