Intent to Ship: HTTPS Upgrades

[Chris Thompson]

Contact emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://github.com/whatwg/fetch/pull/1655

Summary

Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.

Blink component

Internals>Network>SSL

TAG review

Fetch change process does not mention a TAG review, therefore this is N/A (https://github.com/whatwg/fetch#pull-requests)

TAG review status

Not 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.

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?

No

Flag name

https-upgrades

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1394910

Launch bug

https://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.

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 discussions

Intent 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.

[Rik Cabanier]

This is an awesome change that will make the web better!

Did you run any experiments or origin trials to see how it works in the field? Are you planning on rolling it out slowly to see the impact?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46TuPDmzpr8udxXEythTCMVDBVVuTKwQivGGxm5fhJ-Xfg%40mail.gmail.com.

[Chris Thompson]

We're planning to roll this out as a field trial, hopefully starting in Chrome 115 at 1% Stable in order to keep an eye impact. We've been testing our implementation in Chrome Canary/Dev/Beta channels for a while now to help test the feature and polish our implementation, which largely builds on Chrome's existing "HTTPS-First Mode" (which is enabled for users who toggle the "Always use secure connections" opt-in in Chrome's settings). 

We didn't think that this was a good fit for an Origin Trial as it isn't really site (or user) exposed.

[Mike West]

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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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.

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).

Summary

Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.

Blink component

Internals>Network>SSL

TAG review

Fetch 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).

 

TAG review status

Not 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. :)

 

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?

No

Flag name

https-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?

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1394910

Launch bug

https://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.

[Rik Cabanier]

On Wed, May 24, 2023 at 4:43 PM Chris Thompson <cth...@chromium.org> wrote:

We're planning to roll this out as a field trial, hopefully starting in Chrome 115 at 1% Stable in order to keep an eye impact. We've been testing our implementation in Chrome Canary/Dev/Beta channels for a while now to help test the feature and polish our implementation, which largely builds on Chrome's existing "HTTPS-First Mode" (which is enabled for users who toggle the "Always use secure connections" opt-in in Chrome's settings). 

Thanks!

How are you going to measure the impact? Do you keep an eye on bad redirects, hangs, people complaining?

Also, will you send out a followup when you go to 100% (or revert)? We'd like to turn this on in our chromium based browser as well. 

[Charles Harrison]

I didn't quite understand from the explainer, but is the intention that HTTP redirects will always be upgraded unless it results in a redirect loop? Are there other cases where redirects will not be upgraded.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGN7qDAP_u0PRqva-_SPqeJcR8BLRV4EdpspROA7FAEvVKv-fA%40mail.gmail.com.

[Chris Thompson]

Replying in multiple emails to try to make quoting more obvious. First to mkwst@:

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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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.

 

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.

 

Summary

Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.

Blink component

Internals>Network>SSL

TAG review

Fetch 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 status

Not 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.

 

 

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?

No

Flag name

https-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.

 

 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1394910

Launch bug

https://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.)

[Chris Thompson]

To cabanier@:

On Thu, May 25, 2023 at 7:49 AM Rik Cabanier <caba...@gmail.com> wrote:

On Wed, May 24, 2023 at 4:43 PM Chris Thompson <cth...@chromium.org> wrote:

We're planning to roll this out as a field trial, hopefully starting in Chrome 115 at 1% Stable in order to keep an eye impact. We've been testing our implementation in Chrome Canary/Dev/Beta channels for a while now to help test the feature and polish our implementation, which largely builds on Chrome's existing "HTTPS-First Mode" (which is enabled for users who toggle the "Always use secure connections" opt-in in Chrome's settings). 

Thanks!

How are you going to measure the impact? Do you keep an eye on bad redirects, hangs, people complaining?

Also, will you send out a followup when you go to 100% (or revert)? We'd like to turn this on in our chromium based browser as well. 

We are planning to closely monitor user feedback reports and bugs coming into Monorail. We have some browser metrics for successful vs. unsuccessful upgrades and various error cases, which may help us detect if our estimates are way off (indicating issues that require investigation).

We can commit to following up on this thread when we update our rollout %, up to enabling it at 100% and enabling-by-default in tree.

[Chris Thompson]

To csharrison@:

Yes, all main frame navigation redirects to an HTTP URL would be upgraded to HTTPS.

On fallback, Chrome adds the hostname of the original HTTP URL to an allowlist and will skip upgrading requests to that hostname in the future (this is currently remembered for a period of 7 days). Chrome also has an enterprise policy allowlist to exempt hostnames from being upgraded, and we are adding an "escape hatch" to skip upgrading if the user explicitly types in a URL starting with "http://" in the Omnibox.

Upgrades would continue to apply to each non-allowlisted HTTP hop in a navigation until either (1) a redirect loop is detected, (2) a network error occurs, or (3) our "fast fail" timeout triggers (Chrome currently uses a 3s timer to prevent navigations from hanging and then fails the navigation, which triggers our fallback logic).

[Mike West]

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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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.

 

 

Summary

Automatically and optimistically upgrade all main-frame navigations to HTTPS, with fast fallback to HTTP.

Blink component

Internals>Network>SSL

TAG review

Fetch 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 status

Not 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?

No

Flag name

https-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 bug

https://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" 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

[Rick Byers]

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 <blin...@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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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 can say more authoritatively.

+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. 

--

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+...@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.

[Mike West]

-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 <blin...@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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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 can say more authoritatively.

+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. :)

[Panos Astithas]

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 <blin...@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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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 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

[Harald Alvestrand]

How will this affect login to captive portals (WiFi login), which frequently rely on rewriting HTTP requests?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nHa6MGEkFe5576W1tZ8MkPQ%40mail.gmail.com.

[Chris Thompson]

Thanks all. Some updates:

• We have filed a TAG review request
• 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, 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 : 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.)

[Yoav Weiss]

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
• 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, 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 : 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?

 

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 <blin...@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 <blin...@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 emails

cth...@chromium.org, dad...@google.com

Explainer

https://github.com/dadrian/https-upgrade/blob/main/explainer.md

Specification

https://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)

 

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.

[Chris Thompson]

On Wed, Jun 7, 2023 at 9:41 PM Yoav Weiss <yoav...@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
• 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, 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 : 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 can be used to disable this feature on managed clients (we have a similar policy for Chrome's HTTPS-First Mode, i.e. the opt-in "Always use secure connections" setting)
• 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 -- for HTTPS Upgrades and HTTPS-First Mode we rely on Mixed Content Level 2 to ensure no plaintext subresource requests are sent.)

[Yoav Weiss]

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 <yoav...@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
• 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, 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 : 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 can be used to disable this feature on managed clients (we have a similar policy for Chrome's HTTPS-First Mode, i.e. the opt-in "Always use secure connections" setting)
• 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 -- 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 <blin...@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 <blin...@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, dadrian@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 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

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?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" 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.

--
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+unsubscribe@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.

--
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+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Chris Thompson]

Could you provide more information on what is occurring (or maybe better: file a bug at crbug.com/new with details and link it here)? That's the correct flag to force-disable the feature (you can also disable it during the experimental period in chrome://flags/#https-upgrades).

Note that Chrome has other existing features which upgrade certain navigations to HTTPS (such as schemeless URLs entered into the Omnibox), so you may be seeing those instead. HTTPS-Upgrades is currently only enabled at 50% in Chrome Canary/Dev/Beta.

On Mon, Jul 10, 2023 at 4:43 PM Shezan Baig <shezb...@gmail.com> wrote:

 Hi,
Is there a way to disable this feature?  I tried running the browser with " --disable-features=HttpsUpgrades", but it still seems to be performing these upgrades.
Thanks,
-shez-

[Chris Thompson]

This indicates that the upgrades are due to HSTS, so this is unrelated to HTTPS-Upgrades (this new feature). bloomberg.com is currently on the HSTS preload list, which also applies to subdomains.

On Mon, Jul 10, 2023 at 5:18 PM Shezan Baig <shezb...@gmail.com> wrote:

I see the following in the netlog:

t= 97 [st= 0]      TRANSPORT_SECURITY_STATE_SHOULD_UPGRADE_TO_SSL
                   --> get_sts_state_result = true  <--- this is false in the m115 build
                   --> host = "dsbeta.prod.bloomberg.com"
                   --> host_found_in_hsts_bypass_list = false
                   --> should_upgrade_to_ssl = true
t= 97 [st= 0]     +URL_REQUEST_START_JOB  [dt=25]
                   --> initiator = "not an origin"
                   --> load_flags = 65792 (CAN_USE_RESTRICTED_PREFETCH | MAIN_FRAME_DEPRECATED)
                   --> method = "GET"
                   --> network_isolation_key = "http://bloomberg.com http://bloomberg.com"
                   --> request_type = "main frame"
                   --> site_for_cookies = "SiteForCookies: {site=http://bloomberg.com; schemefully_same=true}"
                   --> url = "http://dsbeta.prod.bloomberg.com/vrs2021/viewer/index.html"
t= 97 [st= 0]        URL_REQUEST_REDIRECT_JOB
                     --> reason = "HSTS"
t= 97 [st= 0]        URL_REQUEST_FAKE_RESPONSE_HEADERS_CREATED
                     --> HTTP/1.1 307 Internal Redirect
                         Location: https://dsbeta.prod.bloomberg.com/vrs2021/viewer/index.html
                         Cross-Origin-Resource-Policy: Cross-Origin
                         Non-Authoritative-Reason: HSTS

On Mon, Jul 10, 2023 at 8:12 PM Shezan Baig <shezb...@gmail.com> wrote:

I am using a locally built chrome.exe (so not one of the Canary/Dev/Beta channels), and doing the following:

116.0.5845.14/chrome.exe --proxy-server=<internal-proxy> http://<internal-url>

This causes the <internal-proxy> to get a "CONNECT <internal-url>:443", which unfortunately the proxy is not currently configured to handle properly (it blocks and times out after a minute).  I can fix the <internal-proxy> to handle it correctly, but rolling out that change may take a while.

In the meantime, I'm trying to workaround the issue by doing:

116.0.5845.14/chrome.exe --disable-features=HttpsUpgrades --proxy-server=<internal-proxy> http://<internal-url>

However, that doesn't seem to make any difference (proxy is still getting a "CONNECT <internal-url>:443").

Note that our previous build (115.0.5790.32) does not do these upgrades, so I don't need any disable-feature switch for the m115 build.  However, the m116 build does these upgrades with or without the disable-feature switch.

Also note that these are locally built chromium binaries (not "Google Chrome"), so it will not participate in the 50% experiments.

Thanks for your quick response!
-shez-

[Shezan Baig]

Ahh, I see.  Do you know if there is a switch to disable HSTS?  (seems to be a new behavior in m116)
Thanks,

-shez-

[Shezan Baig]

Hi,
Is there a way to disable this feature?  I tried running the browser with " --disable-features=HttpsUpgrades", but it still seems to be performing these upgrades.

Thanks,

-shez-

On Wednesday, May 24, 2023 at 7:13:38 PM UTC-4 cth...@chromium.org wrote:

[Shezan Baig]

[Shezan Baig]

I am using a locally built chrome.exe (so not one of the Canary/Dev/Beta channels), and doing the following:

116.0.5845.14/chrome.exe --proxy-server=<internal-proxy> http://<internal-url>

This causes the <internal-proxy> to get a "CONNECT <internal-url>:443", which unfortunately the proxy is not currently configured to handle properly (it blocks and times out after a minute).  I can fix the <internal-proxy> to handle it correctly, but rolling out that change may take a while.

In the meantime, I'm trying to workaround the issue by doing:

116.0.5845.14/chrome.exe --disable-features=HttpsUpgrades --proxy-server=<internal-proxy> http://<internal-url>

However, that doesn't seem to make any difference (proxy is still getting a "CONNECT <internal-url>:443").

Note that our previous build (115.0.5790.32) does not do these upgrades, so I don't need any disable-feature switch for the m115 build.  However, the m116 build does these upgrades with or without the disable-feature switch.

Also note that these are locally built chromium binaries (not "Google Chrome"), so it will not participate in the 50% experiments.

Thanks for your quick response!
-shez-

On Mon, Jul 10, 2023 at 7:47 PM Chris Thompson <cth...@chromium.org> wrote:

[Shezan Baig]

 Hi,
Is there a way to disable this feature?  I tried running the browser with " --disable-features=HttpsUpgrades", but it still seems to be performing these upgrades.
Thanks,
-shez-

On Wednesday, May 24, 2023 at 7:13:38 PM UTC-4 cth...@chromium.org wrote:

[Shezan Baig]

Oh, I see that "bloomberg.com" was added to "net/http/transport_security_state_static.json" in m116... that probably explains it.  I can try remove it from the local build.
Thanks so much for your help!

[Daniel Bratell]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

[Chris Thompson]

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.

[Chris Harrelson]

LGTM2 with the same conditions as Daniel. Thanks also for following up with a summary before proceeding with rollout!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46S28jD1qa6imSeDvR8L33WkNeS3xh2gTkSu91Rr97ZCVQ%40mail.gmail.com.

[Yoav Weiss]

LGTM3 with similar conditions. If the PR takes an unreasonable amount of time to land, please let us know.

[Chris Thompson]

We have iterated on the Fetch spec PR 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

[Yoav Weiss]

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 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.

[Chris Harrelson]

Still LGTM from me too.

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.

[Daniel Bratell]

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

[Chris Thompson]

This is currently enabled at 20% Stable. We have not heard any unexpected feedback yet, and are continuing to monitor for issues and feedback.

[Chris Thompson]

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.

[Chris Thompson]

We enabled HTTPS-Upgrades by default on trunk last week, and are currently rolling out to 100% Stable.

[Mike West]

Fantastic, thanks for the update. Hope it sticks!

-mike

[Franky Rios]

I have a website that needs to receive "Header Enrichment" over HTTP, which reads the MSISDN when the user browses via their mobile data.

Previously, the user accessed via HTTPS, and we would switch to HTTP to perform the "Header Enrichment" reading and then switch back to HTTPS.

With this update, I see that there is a Non-Authoritative-Reason: HttpsUpgrades. It stops the HTTP request and switches it to HTTPS. This prevents me from performing the "Header Enrichment" injection reading over HTTP.

What solution could you provide? Is there any way from my infrastructure to block this Non-Authoritative-Reason: HttpsUpgrades, in other words, to block Chrome from redirecting me to HTTPS?

[Andreas S]

Same situation here @Franky

I'm working for a mobile payment service provider that offers mobile payment in multiple countries in Europe. 

Multiple mobile network operators in Europe like few ones in Poland currently only support end user identification via header enrichment! 

The header enrichment is used for an automatic silent end user identification that allows service providers in subsequent flow (of course via https!) to: 

a) auto-login an already known end user in mobile web

b) offer an end-user the possibility to purchase a good/service without need to enter mobile phone number of a user in mobile web (which would require a media break to validate the number via SMS). 

The enforced https upgrade has a huge negative impact on usability of such services for end-users in mobile web: 

Flow that worked automatically in the past gets now interrupted by a request for confirmation for an unsecure flow -> scares a lot of people as it looks very unprofessional. 

Hope you have a realizable idea to deal with this use case, to offer end users a good user experience again! 

(changing identify flow from HE to redirect loop ot mobile network operator is unfortunately not, as they have very limited ressources :( )

[bul...@hotmail.com]

On Thursday, November 9, 2023 at 11:18:51 AM UTC-5 Andreas S wrote:

Same situation here @Franky

I'm working for a mobile payment service provider that offers mobile payment in multiple countries in Europe. 

Multiple mobile network operators in Europe like few ones in Poland currently only support end user identification via header enrichment! 

The header enrichment is used for an automatic silent end user identification that allows service providers in subsequent flow (of course via https!) to: 

a) auto-login an already known end user in mobile web

b) offer an end-user the possibility to purchase a good/service without need to enter mobile phone number of a user in mobile web (which would require a media break to validate the number via SMS). 

The enforced https upgrade has a huge negative impact on usability of such services for end-users in mobile web: 

Flow that worked automatically in the past gets now interrupted by a request for confirmation for an unsecure flow -> scares a lot of people as it looks very unprofessional. 

Hope you have a realizable idea to deal with this use case, to offer end users a good user experience again! 

(changing identify flow from HE to redirect loop ot mobile network operator is unfortunately not, as they have very limited ressources :( 

ATT Wireless USA (my testing, not easy to look up its exact header name for me, but I've seen it before, partial evidence that ATTW has an transparent port 80 proxy that adds req headers https://howardforums.com/showthread.php/1908276-AT-amp-T-Prepaid-no-IPV6-address?p=17008722#post17008722 ) and Verizon Wireless USA  ( https://news.ycombinator.com/item?id=8500131 ) also add per-customer (I guess per SIM card) GUIDs to clear HTTP req headers, by default. Its not politically correct, for any USA based service provider, to publicly admit or document, they use ISP/customer specific info from an LTE provider's port 80 transparent proxy, if a port 80 transparent proxy exists, but as the post above says, in Poland, is it is standard procedure to use an LTE ISP's metadata to change features and behavior for customer facing websites.

Advocating "can't you just make a smartphone native app and pass Apple and Play store review if you want that info (raw TCP sockets)?" seems the opposite of the goals and purpose of the W3C/WP. So whats the solution, if there is a clear business need, as above, for a browser to navigate to a cleartext port 80 domain and back again, which sounds impossible now? Note, there is no opt-out mechanism from HTTPS upgrades defined in this spec other than a a server delivering a RST TCP packet on port 443 or TLS handshake but invalid/unsigned cert returned, or a many seconds long TCP timeout on port 443.

[João Paiva]

We are observing that this change is breaking traffic going through middleboxes when the upstreams have misconfigured TLS. The main problem is that from the moment a middlebox completes the TLS handshake of the HTTPS-upgraded connection, the fallback cannot be triggered. Although the blog post [link] and the explainer [link] suggest using a 404 response or a specific header from the upstream to trigger the fallback, neither of these options seem to be available in Chrome. Consequently, enterprise proxies need to advise admins to disable the automatic upgrades feature for their users to avoid breaking some traffic. This is a bad outcome both in terms of security and configuration complexity. Ideally we’d like all users to keep this feature enabled, but have it work when middleboxes are involved and the upstream is faulty.

Another critical aspect here is that sometimes middleboxes terminate TLS with the eyeball before contacting the upstream. This can happen for security or performance reasons, to improve UX, or to provide other features. Previously this was acceptable as the middlebox could return an HTML error page if the connection failed. With the introduction of this feature, instead users are unable to access the upstream, only seeing an error message from the middlebox.

If Chrome were to support the opt-out header as outlined in the explainer linked above, middleboxes could return it when upstreams turn out to be unreachable. Alternatively, following the recommendation on this comment [link], if Chrome sent a header identifying the current request as being triggered by the automatic upgrade flow, then middleboxes would be able to redirect to HTTP in these situations. Notice this can’t be done in the general case, since the middlebox might be redirecting the user to a site they didn’t request.

We believe implementing these changes would greatly enhance compatibility with middleboxes and improve the overall user experience,so we appreciate your attention to this matter and eagerly await your feedback

[bul...@hotmail.com]

On Thursday, January 4, 2024 at 12:18:25 PM UTC-5 João Paiva wrote:

We are observing that this change is breaking traffic going through middleboxes when the upstreams have misconfigured TLS. The main problem is that from the moment a middlebox completes the TLS handshake of the HTTPS-upgraded connection, the fallback cannot be triggered. Although the blog post [link] and the explainer [link] suggest using a 404 response or a specific header from the upstream to trigger the fallback, neither of these options seem to be available in Chrome. Consequently, enterprise proxies need to advise admins to disable the automatic upgrades feature for their users to avoid breaking some traffic. This is a bad outcome both in terms of security and configuration complexity. Ideally we’d like all users to keep this feature enabled, but have it work when middleboxes are involved and the upstream is faulty.

Another critical aspect here is that sometimes middleboxes terminate TLS with the eyeball before contacting the upstream. This can happen for security or performance reasons, to improve UX, or to provide other features. Previously this was acceptable as the middlebox could return an HTML error page if the connection failed. With the introduction of this feature, instead users are unable to access the upstream, only seeing an error message from the middlebox.

If Chrome were to support the opt-out header as outlined in the explainer linked above, middleboxes could return it when upstreams turn out to be unreachable. Alternatively, following the recommendation on this comment [link], if Chrome sent a header identifying the current request as being triggered by the automatic upgrade flow, then middleboxes would be able to redirect to HTTP in these situations. Notice this can’t be done in the general case, since the middlebox might be redirecting the user to a site they didn’t request.

We believe implementing these changes would greatly enhance compatibility with middleboxes and improve the overall user experience,so we appreciate your attention to this matter and eagerly await your feedback

This proposal should be withdrawn, as Alphabet/Google/Chrome, didn't/has not implement the standard proposal they introduced.