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.) > >> >> >> 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 >>>>>>>>>> >>>>>>>>>> Explainer >>>>>>>>>> https://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) > > >> >>>>>>> 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 bug >>>>>>>>>> https://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 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" >>>>>>> <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 Status >>>>>>>>>> https://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/CAJ8Nf20mYRwXxCjadR5MuQ5DPj7nHa6MGEkFe5576W1tZ8MkPQ%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/CALMy46Sqzr12i6xeSS8whDWfVVRU%3DLgH_m%2B3QO2Qj0N9hNpAag%40mail.gmail.com.
