Intent to Prototype: HTTPS Upgrades
Chris Thompson
Contact emails
cth...@chromium.org, dad...@chromium.orgExplainer
https://github.com/dadrian/https-upgrade/blob/main/explainer.mdSpecification
Summary
Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.
Blink component
Internals>NetworkMotivation
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 (https://hstspreload.org). 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
https://github.com/WICG/proposals/issues/63TAG review
TAG review status
PendingRisks
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?
Debuggability
Is this feature fully tested by web-platform-tests?
NoFlag name
Requires code in //chrome?
TrueTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1394910Estimated milestones
No milestones specified