Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Patrick Meenan]

FWIW, this is already possible in an extension using the devtools protocol
support.  Fetch.continueRequest

lets
you rewrite outbound requests to go to different destinations, modify
headers, etc.  It is what WebPageTest uses to allow you to point a
production site to a dev instance (while keeping the origin the same as
production). Extensions can have access to the devtools protocol so the
existing extension should be able to be modified to do what you need it to
do.

On Tue, Apr 16, 2024 at 2:48 PM David Benjamin 
wrote:

> Keep in mind also that cross-origin and same-origin requests generally
> behave very differently on the web, not just in this specific way. So if
> you're redirecting a portion of your origin in your dev environment, other
> things will also behave differently. I recognize that's not how your
> current dev environment works, and I gather none of the other differences
> had impacted you thus far. But if we could enable a setup where they appear
> at the same origin in the browser, your dev environment would more
> accurately reflect production.
>
> For example, perhaps your backend server could proxy the frontend portions
> from the real frontend, so that it would all appear at the same origin. I
> think you wouldn't need any browser help to achieve that one. Or perhaps (I
> don't work on DevTools, so I'm just spitballing) there could be some
> DevTools features to configure some kind of transparent redirection of URL
> patterns on the browser side.
>
> On Tue, Apr 16, 2024 at 2:28 PM Mike Taylor 
> wrote:
>
>> It's possible that DevTools could support this use case, so I'd encourage
>> you to a feature request at crbug.com/new. Thx
>> On 4/16/24 6:29 AM, Tom Komarnicki wrote:
>>
>> Hi there,
>>
>> Here's the scenario I'm dealing with:
>>
>> I'm a backend developer working on a system with two distinct parts that
>> typically don't intersect during development. The frontend is hosted
>> online, and that's the only place I can access it. When something goes
>> wrong on the backend I'm developing, I usually relied on chrome extensions
>> re-routing my traffic to my localhost using a Chrome extension. This used
>> to work fine, but recently, I've been encountering a 401 error due to the
>> authorization header missing from the redirected request.
>>
>> Now, I'm left with two options: either manually extract data from the
>> developer console or use tools like Fiddler and send requests via Postman
>> to a locally hosted server. Both methods are quite time-consuming compared
>> to the previous setup.
>>
>> I'm wondering if there's a way to configure Chrome to retain all headers
>> on redirect, as it used to function before. This would streamline the
>> debugging process significantly.
>>
>> Thanks!
>>
>> On Tuesday 16 April 2024 at 05:15:30 UTC+3 Yoav Weiss (@Shopify) wrote:
>>
>>> On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki 
>>> wrote:
>>>
 Hey,

 Sorry for necro'ing this thread, I'm aware that this has been on the
 "done" pile for a while - and maybe it should've been brought up earlier,
 but how do you "disable" this feature ? It's making the BE dev exhaustingly
 painful, not being able to intercept requests and re-forward them to the
 local BE.
 Is there a flag, or whatnot, to re-enable the old flow ?

>>>
>>> Can you expand on the issue you're hitting? By "BE" do you mean backend?
>>> Or something else?
>>>
>>>
 Thanks

 On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:

> LGTM3
>
> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>>
>> LGTM1
>>
>>
>>
>> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi 
>> wrote:
>>
>>> Hi, sorry for the long delay.
>>>
>>> The feature page
>>> 
>>> 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
>> 
>> 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.ioa...@gmail.com> wrote:
>>>

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[David Benjamin]

Keep in mind also that cross-origin and same-origin requests generally
behave very differently on the web, not just in this specific way. So if
you're redirecting a portion of your origin in your dev environment, other
things will also behave differently. I recognize that's not how your
current dev environment works, and I gather none of the other differences
had impacted you thus far. But if we could enable a setup where they appear
at the same origin in the browser, your dev environment would more
accurately reflect production.

For example, perhaps your backend server could proxy the frontend portions
from the real frontend, so that it would all appear at the same origin. I
think you wouldn't need any browser help to achieve that one. Or perhaps (I
don't work on DevTools, so I'm just spitballing) there could be some
DevTools features to configure some kind of transparent redirection of URL
patterns on the browser side.

On Tue, Apr 16, 2024 at 2:28 PM Mike Taylor  wrote:

> It's possible that DevTools could support this use case, so I'd encourage
> you to a feature request at crbug.com/new. Thx
> On 4/16/24 6:29 AM, Tom Komarnicki wrote:
>
> Hi there,
>
> Here's the scenario I'm dealing with:
>
> I'm a backend developer working on a system with two distinct parts that
> typically don't intersect during development. The frontend is hosted
> online, and that's the only place I can access it. When something goes
> wrong on the backend I'm developing, I usually relied on chrome extensions
> re-routing my traffic to my localhost using a Chrome extension. This used
> to work fine, but recently, I've been encountering a 401 error due to the
> authorization header missing from the redirected request.
>
> Now, I'm left with two options: either manually extract data from the
> developer console or use tools like Fiddler and send requests via Postman
> to a locally hosted server. Both methods are quite time-consuming compared
> to the previous setup.
>
> I'm wondering if there's a way to configure Chrome to retain all headers
> on redirect, as it used to function before. This would streamline the
> debugging process significantly.
>
> Thanks!
>
> On Tuesday 16 April 2024 at 05:15:30 UTC+3 Yoav Weiss (@Shopify) wrote:
>
>> On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki 
>> wrote:
>>
>>> Hey,
>>>
>>> Sorry for necro'ing this thread, I'm aware that this has been on the
>>> "done" pile for a while - and maybe it should've been brought up earlier,
>>> but how do you "disable" this feature ? It's making the BE dev exhaustingly
>>> painful, not being able to intercept requests and re-forward them to the
>>> local BE.
>>> Is there a flag, or whatnot, to re-enable the old flow ?
>>>
>>
>> Can you expand on the issue you're hitting? By "BE" do you mean backend?
>> Or something else?
>>
>>
>>> Thanks
>>>
>>> On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:
>>>
 LGTM3

 On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor 
 wrote:

> LGTM2
> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi 
> wrote:
>
>> Hi, sorry for the long delay.
>>
>> The feature page
>> 
>> 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
> 
> 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.ioa...@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 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Mike Taylor]

It's possible that DevTools could support this use case, so I'd 
encourage you to a feature request at crbug.com/new. Thx


On 4/16/24 6:29 AM, Tom Komarnicki wrote:

Hi there,

Here's the scenario I'm dealing with:

I'm a backend developer working on a system with two distinct parts 
that typically don't intersect during development. The frontend is 
hosted online, and that's the only place I can access it. When 
something goes wrong on the backend I'm developing, I usually relied 
on chrome extensions re-routing my traffic to my localhost using a 
Chrome extension. This used to work fine, but recently, I've been 
encountering a 401 error due to the authorization header missing from 
the redirected request.


Now, I'm left with two options: either manually extract data from the 
developer console or use tools like Fiddler and send requests via 
Postman to a locally hosted server. Both methods are quite 
time-consuming compared to the previous setup.


I'm wondering if there's a way to configure Chrome to retain all 
headers on redirect, as it used to function before. This would 
streamline the debugging process significantly.


Thanks!

On Tuesday 16 April 2024 at 05:15:30 UTC+3 Yoav Weiss (@Shopify) wrote:

On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki
 wrote:

Hey,

Sorry for necro'ing this thread, I'm aware that this has been
on the "done" pile for a while - and maybe it should've been
brought up earlier, but how do you "disable" this feature ?
It's making the BE dev exhaustingly painful, not being able to
intercept requests and re-forward them to the local BE.
Is there a flag, or whatnot, to re-enable the old flow ?


Can you expand on the issue you're hitting? By "BE" do you mean
backend? Or something else?

Thanks

On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson
wrote:

LGTM3

On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor
 wrote:

LGTM2

On 9/3/23 8:12 PM, Yoav Weiss wrote:

LGTM1



On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi
 wrote:

Hi, sorry for the long delay.

The feature page


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


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  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:

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Tom Komarnicki]

Hi there,

Here's the scenario I'm dealing with:

I'm a backend developer working on a system with two distinct parts that 
typically don't intersect during development. The frontend is hosted 
online, and that's the only place I can access it. When something goes 
wrong on the backend I'm developing, I usually relied on chrome extensions 
re-routing my traffic to my localhost using a Chrome extension. This used 
to work fine, but recently, I've been encountering a 401 error due to the 
authorization header missing from the redirected request.

Now, I'm left with two options: either manually extract data from the 
developer console or use tools like Fiddler and send requests via Postman 
to a locally hosted server. Both methods are quite time-consuming compared 
to the previous setup.

I'm wondering if there's a way to configure Chrome to retain all headers on 
redirect, as it used to function before. This would streamline the 
debugging process significantly.

Thanks!

On Tuesday 16 April 2024 at 05:15:30 UTC+3 Yoav Weiss (@Shopify) wrote:

> On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki  
> wrote:
>
>> Hey,
>>
>> Sorry for necro'ing this thread, I'm aware that this has been on the 
>> "done" pile for a while - and maybe it should've been brought up earlier, 
>> but how do you "disable" this feature ? It's making the BE dev exhaustingly 
>> painful, not being able to intercept requests and re-forward them to the 
>> local BE.
>> Is there a flag, or whatnot, to re-enable the old flow ?
>>
>
> Can you expand on the issue you're hitting? By "BE" do you mean backend? 
> Or something else?
>  
>
>> Thanks
>>
>> On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:
>>
>>> LGTM3
>>>
>>> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor  wrote:
>>>
 LGTM2
 On 9/3/23 8:12 PM, Yoav Weiss wrote:

 LGTM1 



 On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi  
 wrote:

> Hi, sorry for the long delay. 
>
> The feature page 
>  
> 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 
 
  
 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.ioa...@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  
> wrote:
>
>> Friendly ping on the above :) Does (1) sound reasonable from your 
>> perspective?
>>
>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  
>> wrote:
>>
>>> The way I see this, given that the usecounter is an order of 
>>> magnitude higher than what we can consider 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss (@Shopify)]

On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki 
wrote:

> Hey,
>
> Sorry for necro'ing this thread, I'm aware that this has been on the
> "done" pile for a while - and maybe it should've been brought up earlier,
> but how do you "disable" this feature ? It's making the BE dev exhaustingly
> painful, not being able to intercept requests and re-forward them to the
> local BE.
> Is there a flag, or whatnot, to re-enable the old flow ?
>

Can you expand on the issue you're hitting? By "BE" do you mean backend? Or
something else?


> Thanks
>
> On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:
>
>> LGTM3
>>
>> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor  wrote:
>>
>>> LGTM2
>>> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>>>
>>> LGTM1
>>>
>>>
>>>
>>> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi 
>>> wrote:
>>>
 Hi, sorry for the long delay.

 The feature page
 
 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
>>> 
>>> 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.ioa...@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 
 wrote:

> Friendly ping on the above :) Does (1) sound reasonable from your
> perspective?
>
> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
> 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
>> ,
>> 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 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Tom Komarnicki]

Hey,

Sorry for necro'ing this thread, I'm aware that this has been on the "done" 
pile for a while - and maybe it should've been brought up earlier, but how 
do you "disable" this feature ? It's making the BE dev exhaustingly 
painful, not being able to intercept requests and re-forward them to the 
local BE.
Is there a flag, or whatnot, to re-enable the old flow ?
Thanks

On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:

> LGTM3
>
> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor  wrote:
>
>> LGTM2
>> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>>
>> LGTM1 
>>
>>
>>
>> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi  
>> wrote:
>>
>>> Hi, sorry for the long delay. 
>>>
>>> The feature page 
>>>  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 
>> 
>>  
>> 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.ioa...@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  
>> 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  
>>> wrote:
>>>
 Friendly ping on the above :) Does (1) sound reasonable from your 
 perspective?

 On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  
 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 
> ,
>  
> 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 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Chris Harrelson]

LGTM3

On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor  wrote:

> LGTM2
> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi 
> wrote:
>
>> Hi, sorry for the long delay.
>>
>> The feature page
>>  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
> 
> 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 
> 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 
>> wrote:
>>
>>> Friendly ping on the above :) Does (1) sound reasonable from your
>>> perspective?
>>>
>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
>>> 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
 ,
 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 
 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
>>  
>> which
>> looks like it should have made the 112 branch point
>> .  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 
>> wrote:
>>
>>> Am I reading the feature page
>>> 

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Mike Taylor]

LGTM2

On 9/3/23 8:12 PM, Yoav Weiss wrote:

LGTM1



On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi  
wrote:


Hi, sorry for the long delay.

The feature page

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 
 
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
 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
 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
 wrote:

Friendly ping on the above :) Does (1)
sound reasonable from your perspective?

On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss
 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

,
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  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 
   

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

LGTM1



On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi  wrote:

> Hi, sorry for the long delay.
>
> The feature page
>  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

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 
 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 
> wrote:
>
>> Friendly ping on the above :) Does (1) sound reasonable from your
>> perspective?
>>
>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
>> 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
>>> ,
>>> 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 
>>> 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 
 wrote:

> Looks like the feature flag was added Feb 16
>  
> which
> looks like it should have made the 112 branch point
> .  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 
> wrote:
>
>> Am I reading the feature page
>>  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 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

Hi, sorry for the long delay.

The feature page
 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,

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 
>>> 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  wrote:

> Friendly ping on the above :) Does (1) sound reasonable from your
> perspective?
>
> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
> 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
>> ,
>> 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 
>> 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 
>>> wrote:
>>>
 Looks like the feature flag was added Feb 16
  
 which
 looks like it should have made the 112 branch point
 .  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 
 wrote:

> Am I reading the feature page
>  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 
> 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
>>> ).
>>> I'll add a feature flag to prepare for reverting this change if 
>>> breakage is
>>> 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Ioan-Cristian Linte]

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  
>> 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  wrote:
>>>
 Friendly ping on the above :) Does (1) sound reasonable from your 
 perspective?

 On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  
 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 
> ,
>  
> 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  
> 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  
>> wrote:
>>
>>> Looks like the feature flag was added Feb 16 
>>>  
>>> which 
>>> looks like it should have made the 112 branch point 
>>> .  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  
>>> wrote:
>>>
 Am I reading the feature page 
  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  
 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 
>> ).
>>  
>> 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  
>> 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 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

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  
> 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  wrote:
>>
>>> Friendly ping on the above :) Does (1) sound reasonable from your 
>>> perspective?
>>>
>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  
>>> 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 
 ,
  
 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  
 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  
> wrote:
>
>> Looks like the feature flag was added Feb 16 
>>  
>> which 
>> looks like it should have made the 112 branch point 
>> .  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  
>> wrote:
>>
>>> Am I reading the feature page 
>>>  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  
>>> 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 
> ). 
> 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  
> 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 <
 yoavwe...@chromium.org> wrote:

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

Sounds great, thanks!! :)

On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi 
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  wrote:
>
>> Friendly ping on the above :) Does (1) sound reasonable from your
>> perspective?
>>
>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
>> 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
>>> ,
>>> 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 
>>> 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 
 wrote:

> Looks like the feature flag was added Feb 16
>  which
> looks like it should have made the 112 branch point
> .  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 
> wrote:
>
>> Am I reading the feature page
>>  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 
>> 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
 ).
 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 
 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 <
>>> yoavwe...@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

 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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  wrote:

> Friendly ping on the above :) Does (1) sound reasonable from your
> perspective?
>
> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  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
>> ,
>> 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 
>> 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 
>>> wrote:
>>>
 Looks like the feature flag was added Feb 16
  which
 looks like it should have made the 112 branch point
 .  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 
 wrote:

> Am I reading the feature page
>  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 
> 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
>>> ).
>>> 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 
>>> 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 <
>> yoavwe...@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

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

Friendly ping on the above :) Does (1) sound reasonable from your
perspective?

On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss  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
> ,
> 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 
> 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 
>> wrote:
>>
>>> Looks like the feature flag was added Feb 16
>>>  which
>>> looks like it should have made the 112 branch point
>>> .  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 
>>> wrote:
>>>
 Am I reading the feature page
  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 
 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 
> wrote:
>
>> Thank you Yoav for the suggestion. I couldn't find sample URLs from
>> the HTTPArchive data (feature usage
>> ).
>> 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 
>> 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 
> 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
>> 
>>
>> TAG review
>> Not applicable, the spec has been already updated.
>> https://github.com/whatwg/fetch/pull/1544
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

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
,
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  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 
> wrote:
>
>> Looks like the feature flag was added Feb 16
>>  which
>> looks like it should have made the 112 branch point
>> .  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  wrote:
>>
>>> Am I reading the feature page
>>>  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 
>>> 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 
 wrote:

> Thank you Yoav for the suggestion. I couldn't find sample URLs from
> the HTTPArchive data (feature usage
> ).
> 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 
> 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 
>> 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 
 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
> 
>
> 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 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Patrick Meenan]

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  wrote:

> Looks like the feature flag was added Feb 16
>  which
> looks like it should have made the 112 branch point
> .  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  wrote:
>
>> Am I reading the feature page
>>  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 
>> 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 
>>> wrote:
>>>
 Thank you Yoav for the suggestion. I couldn't find sample URLs from the
 HTTPArchive data (feature usage
 ).
 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 
 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 
> 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 
>> 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 
>>> 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
 

 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
 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Patrick Meenan]

Looks like the feature flag was added Feb 16
 which
looks like it should have made the 112 branch point
.  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  wrote:

> Am I reading the feature page
>  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 
> 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 
>> wrote:
>>
>>> Thank you Yoav for the suggestion. I couldn't find sample URLs from the
>>> HTTPArchive data (feature usage
>>> ).
>>> 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 
>>> 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 
 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 
> 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 
>> 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
>>> 
>>>
>>> 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
>>> 
>>> ?Yes
>>> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
>>> any.html?label=master=experimental
>>> https://wpt.fyi/results/fetch/api/credentials/
>>> authentication-redirection.any.html?label=experimental
>>>
>>> Flag nameNot applicable
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

['Rick Viscomi' via blink-dev]

Am I reading the feature page
 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  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 
> wrote:
>
>> Thank you Yoav for the suggestion. I couldn't find sample URLs from the
>> HTTPArchive data (feature usage
>> ).
>> 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 
>> 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 
>>> 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 
 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 
> 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
>> 
>>
>> 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
>> 
>> ?Yes
>> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
>> any.html?label=master=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 Statushttps://chromestatus.com/
>> feature/5195900413018112
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

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 
wrote:

> Thank you Yoav for the suggestion. I couldn't find sample URLs from the
> HTTPArchive data (feature usage
> ).
> 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  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 
>> 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 
>>> 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 
 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
> 
>
> 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
> 
> ?Yes
> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
> any.html?label=master=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 Statushttps://chromestatus.com/
> feature/5195900413018112
>
> This intent message was generated by Chrome Platform Status
> .
>


-- 
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/CAL5BFfVEck2vDTaeo%2BG0f0fJNCe2RtrM7WLJzcn9yOjbMWGMgA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

Thank you Yoav for the suggestion. I couldn't find sample URLs from the
HTTPArchive data (feature usage
). 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  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 
> 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 
>> 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 
>>> 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
 

 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
 
 ?Yes
 https://wpt.fyi/results/xhr/xhr-authorization-redirect.
 any.html?label=master=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 Statushttps://chromestatus.com/
 feature/5195900413018112

 This intent message was generated by Chrome Platform Status
 .

>>>

-- 
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/CAPLXX--BS0Xx1aipT2Nt0hGfkDbgL1qFk-mFQ65%3Dfqj38zoEjg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

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 
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 
> 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 
>> 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
>>> 
>>>
>>> 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
>>> 
>>> ?Yes
>>> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
>>> any.html?label=master=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 Statushttps://chromestatus.com/
>>> feature/5195900413018112
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>

-- 
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/CAL5BFfV3-%2Br40xya841f_hOV9ncR%2B%3Dr2zOsCMWy_9VVcKzK1fw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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 
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  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
>> 
>>
>> 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
>> 
>> ?Yes
>> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
>> any.html?label=master=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 Statushttps://chromestatus.com/
>> feature/5195900413018112
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

-- 
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/CAPLXX-9gLUwMLgSzOxMjh9uKqikw2UWsdm9SxG0-maJ7bXp4mA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

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  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
> 
>
> 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
> 
> ?Yes
> https://wpt.fyi/results/xhr/xhr-authorization-redirect.
> any.html?label=master=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 Statushttps://chromestatus.com/
> feature/5195900413018112
>
> This intent message was generated by Chrome Platform Status
> .
>

-- 
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/CAPLXX-8oNUot5h2cd_XbBQ9ayeYDFJDOfcEVLmNQ%3D15zFXnbtg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

[Yoav Weiss]

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 


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?
 

*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 

?Yes
https://wpt.fyi/results/xhr/xhr-authorization-redirect.
any.html?label=master=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 Statushttps://chromestatus.com/
feature/5195900413018112

This intent message was generated by Chrome Platform Status 
.

-- 
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/f6b68f5f-060f-40c9-b542-2a4e6712eb74n%40chromium.org.