-mike
On Wed, May 31, 2023 at 4:17 PM Rick Byers <rby...@chromium.org> wrote: > As a long-time user of HTTPS-first mode, I'm excited to see this ship ASAP! > > On Wed, May 31, 2023, 5:29 a.m. 'Mike West' via blink-dev < > blink-dev@chromium.org> wrote: > >> On Fri, May 26, 2023 at 1:32 AM Chris Thompson <cth...@chromium.org> >> wrote: >> >>> On Thu, May 25, 2023 at 3:36 AM Mike West <mk...@chromium.org> wrote: >>> >>>> 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 >>>>> >>>>> Explainer >>>>> https://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. >>>> >>> >>> Yes, hopefully we can get some feedback, but I'm optimistic that we >>> won't be locking in behavior if we ship this as it should hopefully be not >>> site or user visible, so if we need to change the behavior to align >>> cross-browser we can iterate. >>> >> >> I left a few comments last week. I think the PR needs some work before we >> can reasonably expect it to land in Fetch. >> >> 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). >>>> >>> >>> We do not have Web Platform Tests but we can look into adding them. >>> Currently this is implemented in //chrome which I think might make this >>> more difficult (my understanding is that the WPT suite is run against >>> content_shell rather than chrome). We are currently relying on browser >>> tests for our integration testing. >>> >> >> WPT is a pretty important part of shipping features that affect the >> platform. It would be ideal if we could share these tests with our friends >> at other vendors (and update existing tests that might be expecting >> different behavior). Shifting the implementation to //content to make that >> possible would also have the advantage of helping other Chromium embedders >> ship this feature, which would be excellent for consistency in the project. >> > > Note that the official WPT results on wpt.fyi are using full Chrome > builds. IIRC there are other features that require Chrome. I personally > only consider having WPTs passing on upstream infra to be blocking I2S. @Panos > Astithas <pastit...@google.com> can say more authoritatively. > > +1 to the benefits of having this in content, but I personally think > that's outside the scope of API owners so not something that should block > an I2S. > I agree with this. I didn't mean to imply that //content implementation was necessary, but that _having_ web platform tests is important for interop. Browser tests are less useful in that regard. :) > > >> 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). >>>> >>>> >>> >>> Sure, we can file a TAG review. I'll update this thread once that's done. >>> >>> >>>> 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. >>>> :) >>>> >>> >>> Good idea. I'll get a CL up to add this to our implementation, and it >>> seems reasonable to merge back to M115. We can include a mention of it in >>> any public facing documentation we write about this. I'm also looking into >>> whether we can add NetLog events for the upgrade and fallback steps which >>> could help with triaging bug reports. >>> >> >> Thanks! >> >> 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? >>>> >>> >>> This feature is currently implemented in //chrome with some support code >>> in content/'s NavigationRequest. I think it would be feasible to migrate >>> the core of this into content/ -- we use an URLRequestLoaderInterceptor and >>> a NavigationThrottle to implement the upgrading and fallback logic. This is >>> currently shared with Chrome's HTTPS-First Mode (controlled by Chrome's >>> "Always use secure connections" setting). If we did migrate this logic to >>> content/, embedders would need to add their own support for at least (1) >>> how to handle allowlisting hostnames, and (2) enterprise policies for >>> enabling/disabling the feature and exempting hostnames. We do not have a >>> design ready for making this change though. >>> >> >> As mentioned above, it would be ideal for the pieces of this change that >> affect the platform to be available in //content so they flow into >> content_shell and other embedders. >> >>> >>> >>>> >>>> >>>>> Tracking bug >>>>> https://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. >>>> >>>> >>> We are hoping to ramp up to 100% within M115, but it may end up >>> completing in M116. >>> >>> (We could do an I2E, but it did not seem like a good fit as there is no >>> Origin Trial component, this does not require developer involvement, etc. >>> Our understanding was even doing a non-OT 1% Stable rollout required >>> sending an I2S and getting LGTMs from API OWNERS. Let us know if you think >>> we should reassess our launch plan.) >>> >> >> We do have an experimentation path for running a Finch experiment on >> stable/beta users (confusingly(?) under "Origin Trial" >> <https://www.chromium.org/blink/launching-features/#:~:text=Depending%20on%20your,required%20before%20proceeding.> >> in our documentation; we could probably improve that). >> >> I think I'd recommend that path to avoid any delays that might come up in >> getting Fetch updated to support this feature. I'd LGTM an I2E @ 50% >> beta/1% stable to gain confidence in the fallback mechanism at scale. For >> I2S, I'm a little worried about the state of the spec and its eventual >> interoperability across vendors. I'd like to get that hammered down before >> making it harder to change details that developers might come to rely upon. >> >> -mike >> >> >>> >>> >>> >>>> 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%3DdPs5Spya9QBVmFYdeTJevs6jML%3DNmU7SEApOshNRmHCg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPs5Spya9QBVmFYdeTJevs6jML%3DNmU7SEApOshNRmHCg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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%3DeMsWAQBpJS%2B12KFWCA4P-pcTRUGbyWaZn2-AKbnrQi6A%40mail.gmail.com.
