Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.
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).
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No milestones specified