LGTM3 On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor <[email protected]> wrote:
> LGTM2 > On 9/3/23 8:12 PM, Yoav Weiss wrote: > > LGTM1 > > > > On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Friendly ping on the above :) Does (1) sound reasonable from your >>>>>>> perspective? >>>>>>> >>>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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 [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw97CtGPnWE5ajBEQP_FEQ3h9LNOzjLabn_aZTwPv%3D%2B9Eg%40mail.gmail.com.
