こんにちは TAG-さん!

I'm requesting a TAG review of HTTPS Upgrades.

Browsers may still make insecure HTTP requests to HTTPS-enabled sites, unnecessarily exposing data over unencrypted connections. Some browsers ship with lists of sites that are known to support HTTPS, beyond those already in the HSTS preload list. Maintaining such a list is opaque, as it requires web crawler data, and error prone, as it will necessarily be out of date by the time it is shipped to users. It can also be bandwidth intensive, containing thousands or millions of sites that need to be updated. HTTPS Upgrades proposes that the browser should automatically and optimistically upgrade all main-frame HTTP navigations to HTTPS, with fast fallback to HTTP.

• Explainer
• Specification URL (Fetch PR)
• Tests: WPT tests are in-progress
• User research: N/A
• Security and Privacy self-review
• GitHub repo (if you prefer feedback filed there): File feedback on this issue
• Primary contacts (and their relationship to the specification):
  • Chris Thompson (@christhompson, Google Chrome)
  • David Adrian (@dadrian, Google Chrome)
• Organization(s)/project(s) driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Gecko: Positive signals (https://github.com/mozilla/standards-positions/issues/800)
  • WebKit: No signal yet (https://github.com/WebKit/standards-positions/issues/185)
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): ChromeStatus entry for this feature

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We are hoping to experiment/ship in Chrome 115 which is being released to Stable on July 18.
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification:
  • mkwst@ flagged that we should consider specifying the upgrade/fallback as synthetic redirects to more closely align with our implementation (similar to an outstanding Fetch issue on HSTS)
  • There is no previously defined concept for "non-unique hostnames" in Fetch or URL specs, but Chrome exempts these hostnames from HTTPS Upgrades (as they are very unlikely to support HTTPS and can be a source of breakage especially in enterprise configurations). One option would be to give a fairly generous affordance to UAs to exempt hosts as they see fit. Another option would be to try to specify this more robustly so we could align cross-UA on exempting these kinds of hosts.
• This work is being funded by: Google Chrome

You should also know that...

This feature is implemented and can be tested in Chrome Canary/Dev/Beta by enabling chrome://flags#https-upgrades. It uses the same underlying code as Chrome's "HTTPS-First Mode" which can be enabled in chrome://settings/security by toggling the "Always use secure connections" setting.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @christhompson and @dadrian