I am enthusiastic about this (and not just because it should allow us to deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline:
On Thu, May 25, 2023 at 1:13 AM Chris Thompson <cth...@chromium.org> wrote: > Contact emailscth...@chromium.org, dadr...@google.com > > Explainerhttps://github.com/dadrian/https-upgrade/blob/main/explainer.md > > Specificationhttps://github.com/whatwg/fetch/pull/1655 > Thanks for putting this together! I'll leave some comments on the PR. Given that we haven't gotten any feedback from Fetch editors, it might be prudent to let them take a pass before locking in our current behavior. Do we have tests in place for this behavior in Web Platform Tests? https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label=experimental&label=master&aligned holds some tests for subresources, but I didn't see any around navigation or fallback behavior (which seems like it might need some WPT infrastructure change to produce a domain that's only served over HTTP). 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) > Blink's process does mention a TAG review. I think it would be a good idea to put this in front of them. I also think they will appreciate it, since it's directly in line with their previous guidance (e.g. https://www.w3.org/2001/tag/doc/web-https). > 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. > For HSTS, we synthesize a `Non-Authoritative-Reason` header on the synthetic redirect that tells developers why the redirect happened. Is that a pattern y'all will follow here as well? If so, it's probably a good idea to document it somewhere; I don't think we've explained that header well. :) > 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 > Can you spell out what's required here? Just enterprise policy work, or are there other things embedders would need to implement to make this functionality work? > 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. > Over what time period do you expect to ramp up to 100%? If you expect it to push beyond the M115 timeframe, it might be reasonable to frame this as an intent to experiment to give folks a little more time to weigh in on the Fetch PR. 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/CAKXHy%3DcrN1J1Kisgq7Sg93H_yAM0wWYN3kBq2YxzPfu96n-A9A%40mail.gmail.com.
