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/CAOMQ%2Bw-Aq8nU%2B5vvDaHa6s6Mz6DGt5ZAco92cWSNfuuHcKv%3DfQ%40mail.gmail.com.
