Fantastic, thanks for the update. Hope it sticks! -mike
On Mon, Oct 16, 2023 at 20:15 Chris Thompson <cth...@chromium.org> wrote: > We enabled HTTPS-Upgrades by default on trunk last week, and are currently > rolling out to 100% Stable. > > On Thu, Oct 5, 2023 at 10:42 AM Chris Thompson <cth...@chromium.org> > wrote: > >> This week we increased the rollout of HTTPS Upgrades up to 35% Stable. We >> are continuing to monitor issues and feedback. Given that we have not heard >> any unexpected feedback yet we are planning to proceed to 100% Stable next >> week. >> >> On Fri, Sep 1, 2023 at 10:42 AM Chris Thompson <cth...@chromium.org> >> wrote: >> >>> This is currently enabled at 20% Stable. We have not heard any >>> unexpected feedback yet, and are continuing to monitor for issues and >>> feedback. >>> >>> On Thu, Aug 24, 2023 at 9:51 AM Daniel Bratell <bratel...@gmail.com> >>> wrote: >>> >>>> Same (LGTM). >>>> >>>> I assume you have also not had any unexpected feedback. The methods you >>>> added to force http seemed adequate but you never know when you encounter >>>> the wild wild web. >>>> >>>> /Daniel >>>> On 2023-08-23 18:45, Chris Harrelson wrote: >>>> >>>> Still LGTM from me too. >>>> >>>> On Wed, Aug 23, 2023 at 8:58 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> 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 >>>>>>>>>> >>>>>>>>>> -- 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%3Ddmtsj0i%3DsYY22oXHOZ-%3D38V9RUd90ebvp8r%2BqE0n649g%40mail.gmail.com.
