Intent to Experiment: 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>HttpsUpgrades

TAG review

https://github.com/w3ctag/design-reviews/issues/853

TAG review status

Pending

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 No specific web developer 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?

Goals for experimentation

Identify and assess breakage (e.g., sites that allow HTTPS connections but are broken or serve different content) and identify any blocking implementation bugs.

Ongoing technical constraints

None -- we believe we are ready to ship pending approvals on our Intent-to-Ship.

Debuggability

Chrome will upgrade these navigations to HTTPS using a 307 internal redirect, which will be visible in the Network panel of Developer Tools. These redirects include a `Non-Authoritative-Reason: HttpsUpgrades` header to identify the source.

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?

Yes (https://wpt.fyi/results/https-upgrades/tentative) 

Flag name on chrome://flags

https-upgrades

Finch feature name

HttpsUpgrades

Non-finch justification

None

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

Estimated milestones

Shipping on desktop	115
DevTrial on desktop	115

Shipping on Android	115
DevTrial on Android	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 ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/OdMMGgLXAgAJ

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.

[Chris Thompson]

Quick additional context for this intent: we have previously sent an Intent-to-Ship for this feature (see https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/OdMMGgLXAgAJ) but we are separately requesting approval to experiment in M115 Stable as our spec change has not yet landed.

[Yoav Weiss]

M115 experimentation LGTM

--
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/CALMy46S8GpznopFP2MdeoBcgN0SfnqZoOM2xrjXYNA9fPr7uYg%40mail.gmail.com.

[Caleb Raitto]

Thanks for making this security-positive change!

Quick question -- what impact, if any, would this have on captive portals? I know some folks visit sites like http://neverssl.com/ to access captive portal pages. If I understand correctly, these pages would still work, since a resource only available via http will still be accessible?

(As a further complication, I recall that http://neverssl.com/ had to use https at some point to get a cacheable page that requests an http-only resource, triggering the captive portal -- we should make sure this doesn't break).

Thanks,

-Caleb

On Wednesday, July 12, 2023 at 1:06:55 AM UTC-4 Yoav Weiss wrote:

M115 experimentation LGTM

On Tue, Jul 11, 2023, 22:53 Chris Thompson <cth...@chromium.org> wrote:

Quick additional context for this intent: we have previously sent an Intent-to-Ship for this feature (see https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/OdMMGgLXAgAJ) but we are separately requesting approval to experiment in M115 Stable as our spec change has not yet landed.

On Tue, Jul 11, 2023 at 1:51 PM Chris Thompson <cth...@chromium.org> wrote:

Contact emails

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Thompson]

It is possible that there are captive portals that could be affected by this, depending on their configuration. The one case that we have seen was a middlebox with an enterprise installed non-publicly trusted root certificate which responded over HTTPS instead of closing the connection or redirecting back to HTTP. For non-enterprise captive portals, they would not be able to serve a publicly trusted certificate on HTTPS, which should result in an automatic downgrade back to HTTP and then the captive portal can redirect/proceed as usual.

The interaction with neverssl.com is known (previously raised in https://github.com/colmmacc/neverssl.com/issues/2 and by us in https://github.com/colmmacc/neverssl.com/issues/12, see the discussions there for the considerations). alwayshttp.com is an alternative which does not respond on HTTPS at all and immediately falls back to HTTP. Especially for power users who use neverssl, we hope that our "explicit typed http:// scheme in Omnibox" escape hatch can be sufficient to let users proceed through this flow if they need the cache-busting behavior.

On Tue, Jul 18, 2023 at 9:17 AM Caleb Raitto <cara...@chromium.org> wrote:

Thanks for making this security-positive change!

Quick question -- what impact, if any, would this have on captive portals? I know some folks visit sites like http://neverssl.com/ to access captive portal pages. If I understand correctly, these pages would still work, since a resource only available via http will still be accessible?

(As a further complication, I recall that http://neverssl.com/ had to use https at some point to get a cacheable page that requests an http-only resource, triggering the captive portal -- we should make sure this doesn't break).

Thanks,

-Caleb

On Wednesday, July 12, 2023 at 1:06:55 AM UTC-4 Yoav Weiss wrote:

M115 experimentation LGTM

On Tue, Jul 11, 2023, 22:53 Chris Thompson <cth...@chromium.org> wrote:

Quick additional context for this intent: we have previously sent an Intent-to-Ship for this feature (see https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/OdMMGgLXAgAJ) but we are separately requesting approval to experiment in M115 Stable as our spec change has not yet landed.

On Tue, Jul 11, 2023 at 1:51 PM Chris Thompson <cth...@chromium.org> wrote:

Contact emails

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Thompson]

Hi Von -- Sorry you are having problems but your issues do not sound related to this feature. If you are having issues with the Chrome browser, you can file a bug report at crbug.com/new. If you are having issues with Android, another Google application, or your cellular carrier, this unfortunately is not the correct venue for support.

Cheers,

Chris

On Tue, Jul 18, 2023 at 4:44 PM Von Johnson <von...@gmail.com> wrote:

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/185)

Web developers: No signals No specific web developer signals. This feature is not exposed directly to web developers or users. However, HTTPS

I don't want this. Do I have a say on what transpires on my device? Is this upgrade to https affecting my network. This is probably the reason I'm having trouble receiving text messages. I use Google messenger, so I think my text messages are web based. They show up. I'm not interested in any additional security. I just want my text messages to work. 

On Tue, Jul 18, 2023, 12:17 PM Caleb Raitto <cara...@chromium.org> wrote:

Thanks for making this security-positive change!

Quick question -- what impact, if any, would this have on captive portals? I know some folks visit sites like http://neverssl.com/ to access captive portal pages. If I understand correctly, these pages would still work, since a resource only available via http will still be accessible?

(As a further complication, I recall that http://neverssl.com/ had to use https at some point to get a cacheable page that requests an http-only resource, triggering the captive portal -- we should make sure this doesn't break).

Thanks,

-Caleb

On Wednesday, July 12, 2023 at 1:06:55 AM UTC-4 Yoav Weiss wrote:

M115 experimentation LGTM

On Tue, Jul 11, 2023, 22:53 Chris Thompson <cth...@chromium.org> wrote:

Quick additional context for this intent: we have previously sent an Intent-to-Ship for this feature (see https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/OdMMGgLXAgAJ) but we are separately requesting approval to experiment in M115 Stable as our spec change has not yet landed.

On Tue, Jul 11, 2023 at 1:51 PM Chris Thompson <cth...@chromium.org> wrote:

Contact emails

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

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/CALMy46S8GpznopFP2MdeoBcgN0SfnqZoOM2xrjXYNA9fPr7uYg%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a06c3cbe-d815-459d-89bb-9927df94923en%40chromium.org.