Contact emailscth...@chromium.org, dadr...@google.com Explainerhttps://github.com/dadrian/https-upgrade/blob/main/explainer.md
Specificationhttps://github.com/whatwg/fetch/pull/1655 Summary Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP. Blink componentInternals>Network>SSL <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> TAG reviewFetch change process does not mention a TAG review, therefore this is N/A (https://github.com/whatwg/fetch#pull-requests) TAG review statusNot applicable Risks Interoperability and Compatibility *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/800) Firefox is offering a similar feature already in their private browsing mode by default *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/185) *Web developers*: No signals. This feature is not exposed directly to web developers or users. However, HTTPS adoption is now standard practice (>90% of page loads in Chrome use HTTPS), and automatically upgrading navigations to HTTPS would avoid unnecessary redirects from HTTP to HTTPS for site owners. The `upgrade-insecure-requests` header has some similar functionality, and according to HTTP-Archive is found on ~6% of all requests. *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 Chrome will upgrade these navigations to HTTPS using a 307 internal redirect, which will be visible in the Network panel of Developer Tools. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No Currently not available on Android WebView. We are implementing this first for Chrome and will consider bringing this to WebView (likely as an embedder opt-in) as follow up work. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No Flag namehttps-upgrades Requires code in //chrome?True Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1394910 Launch bughttps://launch.corp.google.com/launch/4235192 Sample links http://example.com will upgrade to https://example.com. http://www.alwayshttp.com will upgrade to https://www.alwayshttp.com but fall back to http://www.alwayshttp.com because the site doesn't support HTTPS. Estimated milestones Shipping on desktop 115 Shipping on Android 115 We are planning to do a field trial to gradually roll out this feature to Chrome clients in Chrome 115. Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). https://github.com/whatwg/fetch/pull/1655 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6056181032812544 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/mgJqym5-Xek/m/0EAN6v7CCQAJ This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46TuPDmzpr8udxXEythTCMVDBVVuTKwQivGGxm5fhJ-Xfg%40mail.gmail.com.
