Intent to Prototype: HTTPS Upgrades

Skip to first unread message

Chris Thompson

Dec 7, 2022, 12:09:24 PM12/7/22
to blink-dev, David Adrian, Emily Stark, Joe DeBlasio, trusty-transport

Contact emails




Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.

Blink component



Browsers still make insecure HTTP requests to HTTPS-enabled sites, unless site operators have performed a series of elaborate configuration steps culminating in adding their site to the HSTS preload list ( This can happen when the user follows an HTTP link to, or loads an HTTP resource from: - a site that uses HSTS that the browser has not visited before, - a site that redirects HTTP to HTTPS (defaults to HTTPS) but does not use HSTS, - or a site that supports both HTTPS and HTTP and does not redirect HTTP to HTTPS. In all of these cases, users make insecure HTTP connections to sites that support HTTPS, needlessly compromising their privacy and security. Depending on configuration, a browser could initiate anywhere between one and all of its requests to that site over insecure HTTP. Current approaches to upgrades are either limited by complexity and risks (HSTS preload), limited in scope (manually curated upgrade lists), or focused on security-conscious users (like Chrome's HTTPS-First Mode).

Initial public proposal

TAG review

TAG review status



Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?


Is this feature fully tested by web-platform-tests?


Flag name

Requires code in //chrome?


Tracking bug

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
0 new messages