LGTM1
On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <ba...@chromium.org> wrote: > Hi, sorry for the long delay. > > The feature page > <https://chromestatus.com/metrics/feature/timeline/popularity/4470> now > shows sites that use Authorization header for cross-origin redirects. I > randomly picked some of them and examined to see if they could work when > Chrome removes Authorization header up on cross-origin redirects. As far as > I can tell, none of them are broken. We would like to ship this behind a > feature flag. > Thanks for the analysis! As you pointed out elsewhere, since our previous discussions on this thread, this was shipped <https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=stable&label=master&aligned> by Firefox and Safari. I think that changes the risk calculus (from compat to interop) and makes shipping this (with a base feature just in case) the right choice. > Thanks, > > On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte < > linte.ioan.crist...@gmail.com> wrote: > >> Any updates on this? >> Other browser have already made the change for some time so it's >> surprising that Chrome is so worried about breaking change. >> >> The Authorization propagating in cross origin redirects is causing a >> performance issue for us. Our server redirects to AWS S3 with pre-signed >> url and this will return 400 error as AWS S3 disallows specifying multiple >> authorizations (e.g. signature in url and Authorization header) in a >> request. Also the 400 error response includes a close connection header. To >> make this work, the web client checks for the 400 error and uses the >> response.url to make a new fetch request without the Authorization header. >> Because the previous connection was closed this incurs the cost of >> initiating a new connection. >> >> On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote: >> >>> Friendly ping! :) Any news on UKM data here? >>> >>> On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav Weiss wrote: >>> >>>> Sounds great, thanks!! :) >>>> >>>> On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi <ba...@chromium.org> >>>> wrote: >>>> >>>>> Hi Yoav, >>>>> >>>>> Sorry I haven't sent an update in this thread. (1) sounds reasonable. >>>>> I added the usercounters to UKM a few weeks ago and I'm waiting for data. >>>>> I >>>>> will report back after manual inspections are done. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss <yoav...@chromium.org> >>>>> wrote: >>>>> >>>>>> Friendly ping on the above :) Does (1) sound reasonable from your >>>>>> perspective? >>>>>> >>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss <yoav...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> The way I see this, given that the usecounter is an order of >>>>>>> magnitude higher than what we can consider trivial, we have 3 options: >>>>>>> 1) Add the usecounters to UKM >>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounters%20ukm&ss=chromium>, >>>>>>> run an analysis on early data to extract URLs that use this, and >>>>>>> randomly >>>>>>> sample those for manual inspection. >>>>>>> 2) Wait for the HTTPArchive crawl to run with this usecounter, >>>>>>> assuming that unauthed landing pages will trigger it. >>>>>>> 3) Run an HA query that tries to find cross-origin redirects with >>>>>>> Auth headers. I'm not sure how easy (or feasible) that would be, but >>>>>>> Rick >>>>>>> and Pat would know >>>>>>> >>>>>>> To me, (1) seems to be the easiest, and with the least amount of >>>>>>> potential bias (all pages vs. unauthed landing pages). >>>>>>> >>>>>>> On Tue, Mar 14, 2023 at 9:45 PM Patrick Meenan <pme...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Do we expect the Authorization header to be something that the HTTP >>>>>>>> Archive triggers in a way that the feature will trigger? Since they >>>>>>>> are >>>>>>>> all unauthenticated single page loads, it feels like it's unlikely to >>>>>>>> be >>>>>>>> something that we hit. >>>>>>>> >>>>>>>> On Tue, Mar 14, 2023 at 4:37 PM Patrick Meenan <pme...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Looks like the feature flag was added Feb 16 >>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4235597> >>>>>>>>> which >>>>>>>>> looks like it should have made the 112 branch point >>>>>>>>> <https://chromiumdash.appspot.com/schedule>. If we hold the >>>>>>>>> April crawl back a couple of days and start it on the 4th after >>>>>>>>> stable is >>>>>>>>> released then we can pick it up in April, otherwise it would show up >>>>>>>>> mid-crawl. >>>>>>>>> >>>>>>>>> On Tue, Mar 14, 2023 at 4:24 PM Rick Viscomi <rvis...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Am I reading the feature page >>>>>>>>>> <https://chromestatus.com/feature/5195900413018112> correctly >>>>>>>>>> that it'll land in stable version 113? If so, HTTP Archive wouldn't >>>>>>>>>> pick >>>>>>>>>> that up until the May crawl. >>>>>>>>>> >>>>>>>>>> cc @Patrick Meenan to keep me honest >>>>>>>>>> >>>>>>>>>> On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss <yoav...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> It's possible that we need to wait for the next HA run to get >>>>>>>>>>> actual examples. >>>>>>>>>>> +Rick Viscomi would know.. >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 13, 2023 at 12:28 AM Kenichi Ishibashi < >>>>>>>>>>> ba...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you Yoav for the suggestion. I couldn't find sample URLs >>>>>>>>>>>> from the HTTPArchive data (feature usage >>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470>). >>>>>>>>>>>> I'll add a feature flag to prepare for reverting this change if >>>>>>>>>>>> breakage is >>>>>>>>>>>> problematic. >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Mar 10, 2023 at 7:06 PM Yoav Weiss < >>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> One option to tighten the potential for breakage would be to >>>>>>>>>>>>> e.g. sample 10 URLs that are hitting that usecounter (e.g. from >>>>>>>>>>>>> the >>>>>>>>>>>>> HTTPArchive data), and test them manually to see how many of them >>>>>>>>>>>>> would >>>>>>>>>>>>> break once this change is applied. Based on the number you'd get, >>>>>>>>>>>>> we can >>>>>>>>>>>>> estimate the magnitude of breakage we can expect to see in the >>>>>>>>>>>>> wild. >>>>>>>>>>>>> Another option would be to roll this out with a base feature >>>>>>>>>>>>> flag (that we'd want anyway) and be ready to revert if breakage >>>>>>>>>>>>> is more >>>>>>>>>>>>> than we'd like. >>>>>>>>>>>>> >>>>>>>>>>>>> Combining those two options is probably safest. >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 10, 2023 at 8:51 AM Kenichi Ishibashi < >>>>>>>>>>>>> ba...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Use counter reports 0.022%. My guess is that most usage >>>>>>>>>>>>>> happens accidentally but we are not sure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> API owners, should we do a reverse OT? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Feb 17, 2023 at 9:38 AM Kenichi Ishibashi < >>>>>>>>>>>>>> ba...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Quick update, we added a use counter to see how often this >>>>>>>>>>>>>>> could happen. I'll get back once we have data. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Feb 8, 2023 at 11:51 PM Yoav Weiss < >>>>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any use counters on how often this happens? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 Kenichi >>>>>>>>>>>>>>>> Ishibashi wrote: >>>>>>>>>>>>>>>> Contact emailsba...@chromium.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specificationhttps://fetch.spec.whatwg.org/ >>>>>>>>>>>>>>>> #http-redirect-fetch >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Remove Authorization header on cross origin redirects to >>>>>>>>>>>>>>>> scope a developer-controlled Authorization header to the >>>>>>>>>>>>>>>> origin of the >>>>>>>>>>>>>>>> initial request. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink componentBlink>Loader >>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>> Not applicable, the spec has been already updated. >>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/pull/1544 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Low. All browser vendors agreed with this change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Gecko*: Shipping (https://bugzilla.mozilla.org/ >>>>>>>>>>>>>>>> show_bug.cgi?id=1802086) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do we know if they ran into any compat issues when shipping >>>>>>>>>>>>>>>> this? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> None I'm aware of. I checked the bug and related issues in >>>>>>>>>>>>>>> GitHub but I didn't find anything. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_ >>>>>>>>>>>>>>>> bug.cgi?id=230935) Historically Safari always removed >>>>>>>>>>>>>>>> Authorization headers even for the same origin redirects. >>>>>>>>>>>>>>>> Recently the >>>>>>>>>>>>>>>> behavior has changed to preserve them on same origin redirects. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That's encouraging in terms of lack of potential reliance >>>>>>>>>>>>>>>> on these headers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> N/A >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Web Developers can use DevTools network panel to see the >>>>>>>>>>>>>>>> actual request headers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>>> Yes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ?Yes >>>>>>>>>>>>>>>> https://wpt.fyi/results/xhr/xhr-authorization-redirect. >>>>>>>>>>>>>>>> any.html?label=master&label=experimental >>>>>>>>>>>>>>>> https://wpt.fyi/results/fetch/api/credentials/ >>>>>>>>>>>>>>>> authentication-redirection.any.html?label=experimental >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag nameNot applicable >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking bughttps://bugs.chromium.org/p/ >>>>>>>>>>>>>>>> chromium/issues/detail?id=1393520 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> M112 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The spec has been already updated. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/944 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> https://chromestatus.com/feature/5195900413018112 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com.
