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.
>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/CALMy46RjQYCjti9m%2B%3DhtQGPiFmuMU_1vy3MYheQ8K3_MAZcxSQ%40mail.gmail.com.
