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. >>>> >>>> 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/CAOqqYVGCYvT%2B8AbHTo1WLJFd0Dt%2BQQarTvTBvdzmW82LsWHnbw%40mail.gmail.com.
