On Wed, May 31, 2023 at 7:31 AM Mike West <mk...@google.com> wrote:
> > -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. >> > Indeed, upstream WPT results use full Chrome (and Firefox, Safari, etc.) through wptrunner. Soon, this will also be the case when running WPT in Chromium CI on Linux, once some blockers have been resolved. Panos +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/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nHa6MGEkFe5576W1tZ8MkPQ%40mail.gmail.com.
