Re: [w3ctag/design-reviews] HTTPS Upgrades (Issue #853)

We've considered ways that we might avoid unnecessary upgrades for local networks (potentially building on top of some of the work that [Private Network Access](https://wicg.github.io/private-network-access/) is doing). For now we settled on giving fairly open UA carveouts for exemptions in the spec itself -- Chrome's implementation is using this to exempt non-unique hostnames which we know *can't* get publicly trusted TLS certificates. For unique hostnames, there are many cases where these do have trusted TLS certificates despite resolving to local network addresses (e.g., the [Plex model](https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/)). On balance, because HTTPS-Upgrades will silently fallback to HTTP if the HTTPS request fails, this might add a small latency to some local network requests but should not cause breakage.

(For Chrome's "HTTPS-First Mode", which shows a full page warning to the user before falling back to HTTP, we are working on ways that we might reduce this warning burden on users for local network requests, but this is still WIP.)

Regarding a HTTP response header: We considered this when we were first proposing HTTPS-Upgrades but decided against it. An "opt-out" header is roughly equivalent to the site serving an HTTP downgrade redirect or just rejecting the HTTPS request (not responding on HTTPS or sending a reset) -- both will trigger the automatic fallback to HTTP. For sites that *explicitly* don't support HTTPS, we would recommend they serve a downgrade redirect. For the long-tail of sites that won't modify their configs, the new header wouldn't help.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/853#issuecomment-1622149334
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/853/1622149334@github.com>