Still LGTM On Wed, Aug 23, 2023 at 5:47 PM Chris Thompson <cth...@chromium.org> wrote:
> We have iterated on the Fetch spec PR > <https://github.com/whatwg/fetch/pull/1655> and believe it is ready to > land modulo some editorial tweaks. > Please be sure to follow up on the PR once the reviewers get back to it. > > From our 1% Stable experiment, we saw a substantial decrease in insecure > plaintext HTTP navigation requests, and no regressions in Core Web Vitals > metrics. > > We would like to proceed with this Intent-to-Ship, doing a gradual rollout > to 100% in order to continue monitoring potential breakage. > > We did see a possible regression in renderer crash proportion, but we have > not been able to identify a plausible cause or crash signature. Due to this > possible stability risk we will be coordinating our gradual rollout with > release owners. I can update this thread each time we increase our rollout > percentage. > > - Chris > > > > > On Wed, Jul 19, 2023 at 9:01 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> LGTM3 with similar conditions. If the PR takes an unreasonable amount of >> time to land, please let us know. >> >> On Wed, Jul 19, 2023 at 9:02 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> LGTM2 with the same conditions as Daniel. Thanks also for following up >>> with a summary before proceeding with rollout! >>> >>> On Wed, Jul 19, 2023 at 11:56 AM Chris Thompson <cth...@chromium.org> >>> wrote: >>> >>>> Thanks Daniel. As a quick update, this was just enabled at 1% Stable in >>>> M115 (released yesterday). We have not seen any blockers come up from Beta, >>>> but since issues may arise mainly in the long tail of sites we might not >>>> see anything until Stable anyway. We'll keep an eye on our experimental >>>> rollout and follow up here with a summary. >>>> >>>> On Wed, Jul 19, 2023 at 11:52 AM Daniel Bratell <bratel...@gmail.com> >>>> wrote: >>>> >>>>> I've been waiting a bit to see if the experiment would blow anything >>>>> up, but if it doesn't, and continue to not do so, then >>>>> >>>>> LGTM1 as soon as the PR has landed. >>>>> >>>>> /Daniel >>>>> On 2023-06-14 17:40, Yoav Weiss wrote: >>>>> >>>>> >>>>> >>>>> On Thursday, June 8, 2023 at 5:53:49 PM UTC+2 Chris Thompson wrote: >>>>> >>>>> On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>> Thanks for working on this! >>>>> >>>>> On Wed, Jun 7, 2023 at 11:44 PM Chris Thompson <cth...@chromium.org> >>>>> wrote: >>>>> >>>>> Thanks all. Some updates: >>>>> >>>>> - We have filed a TAG review request >>>>> <https://github.com/w3ctag/design-reviews/issues/853> >>>>> - We are working on writing WPTs and we will update this thread >>>>> when those are ready -- thanks for the added details about how those >>>>> are run >>>>> - We have added a `Non-Authoritative-Reason: HttpsUpgrades` header >>>>> to the synthetic redirects (CL >>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4584420>, >>>>> which we are planning to merge back to M-115) >>>>> - We are continuing to iterate on the spec PR >>>>> >>>>> For now we will continue to provide updates on this I2S -- closer to >>>>> M115 going to Stable we may send an I2E to request the ability to proceed >>>>> with a 1% Stable experiment if we have not yet been able to resolve >>>>> everything here. >>>>> >>>>> @Harald Alvestrand <h...@google.com> : In general, this feature should >>>>> work fine with captive portals. A captive portal that intercepts HTTPS >>>>> connections will result in a certificate error, which will cause the >>>>> upgrade to fail and automatically fall back to HTTP. Alternatively, the >>>>> captive portal could reset the connection for HTTPS requests, which would >>>>> accomplish the same. >>>>> >>>>> We have had one report of a middlebox that returned an HTTP 404 error >>>>> over HTTPS instead of rejecting the connection, causing breakage (the >>>>> upgraded HTTPS page would load but have useless content). We do not >>>>> believe >>>>> the browser should fallback on *application* level errors, as they do >>>>> not provide a useful signal that the site does not support HTTPS -- in the >>>>> vast majority of cases the same application error will occur over HTTP as >>>>> well. (This specific case was an enterprise situation, with an enterprise >>>>> installed root certificate making the middlebox's HTTPS work, and we have >>>>> enterprise policies to allow organizations to disable upgrades for >>>>> affected >>>>> hosts.) >>>>> >>>>> >>>>> What's our plan to tackle such issues? Do we have an enterprise policy >>>>> in place? >>>>> >>>>> >>>>> >>>>> We have two enterprise policies for this feature: >>>>> >>>>> - HttpsUpgradesEnabled >>>>> <https://chromeenterprise.google/policies/#HttpsUpgradesEnabled> can >>>>> be used to disable this feature on managed clients (we have a similar >>>>> policy <https://chromeenterprise.google/policies/#HttpsOnlyMode> >>>>> for Chrome's HTTPS-First Mode, i.e. the opt-in "Always use secure >>>>> connections" setting) >>>>> - HttpAllowlist >>>>> <https://chromeenterprise.google/policies/#HttpAllowlist> can be >>>>> used to allowlist hostnames or hostname patterns -- these will then >>>>> not be >>>>> upgraded on managed clients (this also applies to HTTPS-First Mode) >>>>> >>>>> There are two "escape hatches" for users who encounter breakage and >>>>> need to fall back to HTTP, although from prior measurement we expect this >>>>> to be rare: >>>>> >>>>> - If the user explicitly types an "http://"; URL into the Omnibox >>>>> (with the scheme), we skip upgrading that navigation and add the host >>>>> to >>>>> the allowlist. >>>>> - If the user sets the "Insecure Content" content setting ( >>>>> chrome://settings/content/insecureContent) to "Allowed" for the >>>>> site, then we skip upgrading navigations. (This setting also disables >>>>> mixed >>>>> content autoupgrading >>>>> >>>>> <https://w3c.github.io/webappsec-mixed-content/level2.html#upgrade-algorithm> >>>>> -- >>>>> for HTTPS Upgrades and HTTPS-First Mode we rely on Mixed Content Level >>>>> 2 to >>>>> ensure no plaintext subresource requests are sent.) >>>>> >>>>> >>>>> That makes sense! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jun 7, 2023 at 1:02 AM Harald Alvestrand <h...@google.com> >>>>> wrote: >>>>> >>>>> How will this affect login to captive portals (WiFi login), which >>>>> frequently rely on rewriting HTTP requests? >>>>> >>>>> >>>>> On Tue, Jun 6, 2023 at 12:00 AM 'Panos Astithas' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>> 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 >>>>> >>>>> 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. >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> I agree (and left a few comments of my own). Would it be possible to >>>>> make some progress on this? Once the comments are addressed and we feel >>>>> good about the PR's state, could we use the Mozilla position as support >>>>> and >>>>> publish the PR for review? (It's currently marked as a draft, which may >>>>> explain why it wasn't reviewed by Fetch editors) >>>>> >>>>> >>>>> Friendly ping on making progress on the PR! :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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 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 milestonesShipping on desktop115Shipping on Android115 >>>>> >>>>> 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 Statushttps://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/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nH >>>>> a6MGEkFe5576W1tZ8MkPQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nHa6MGEkFe5576W1tZ8MkPQ%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/CALMy46Q--Fj9qV%3D28_ >>>>> CY9au4h-Gc%3D3dYWPFNeT1g-wdmQxEvSQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46Q--Fj9qV%3D28_CY9au4h-Gc%3D3dYWPFNeT1g-wdmQxEvSQ%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/4bb5bcde-794b-44ea-9a04-2c3837eac96dn%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4bb5bcde-794b-44ea-9a04-2c3837eac96dn%40chromium.org?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/CALMy46S28jD1qa6imSeDvR8L33WkNeS3xh2gTkSu91Rr97ZCVQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46S28jD1qa6imSeDvR8L33WkNeS3xh2gTkSu91Rr97ZCVQ%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/CAL5BFfX3oKUmq4F%3DzHZ06_nc-KiVqLN8umYrsgqgCckmP1u1gQ%40mail.gmail.com.
