Intent to Ship: CORS non-wildcard request-header

810 views
Skip to first unread message

Yutaka Hirano

unread,
Oct 21, 2021, 3:55:47 AM10/21/21
to blink-dev

(The implementation CL is under review. This intent is written as if it's landed.)


Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name



Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones. We have an enterprise policy so that administrators can keep the existing behavior. We're planning to remove the policy on Chrome 103. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard



Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals


Debuggability

We'll show a CORS error to the devtools console.



Is this feature fully tested by web-platform-tests?

Yes

Flag name

CorsNonWildcardRequestHeadersSupport

Requires code in //chrome?

False (or, True only for the enterprise policy.)

Tracking bug

https://crbug.com/1176753

Estimated milestones

97


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

Yoav Weiss

unread,
Oct 21, 2021, 5:25:48 AM10/21/21
to Yutaka Hirano, blink-dev
On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

(The implementation CL is under review. This intent is written as if it's landed.)


Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name



Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones.


Can you similarly send deprecation reports as well? How long have the deprecation messages been in place? Did we see any decline in the numbers?

Have we looked into which URLs are triggering this? (and if it's a few medium-sized properties or many tiny ones) 
Did we try outreach?

We have an enterprise policy so that administrators can keep the existing behavior. We're planning to remove the policy on Chrome 103. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard



Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals


Debuggability

We'll show a CORS error to the devtools console.



Is this feature fully tested by web-platform-tests?

Yes

Flag name

CorsNonWildcardRequestHeadersSupport

Requires code in //chrome?

False (or, True only for the enterprise policy.)

Tracking bug

https://crbug.com/1176753

Estimated milestones

97


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

Yutaka Hirano

unread,
Oct 21, 2021, 6:04:53 AM10/21/21
to Yoav Weiss, blink-dev
On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

(The implementation CL is under review. This intent is written as if it's landed.)


Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name



Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones.


Can you similarly send deprecation reports as well? How long have the deprecation messages been in place? Did we see any decline in the numbers?

We've shown the deprecation message since Chrome 94 whose beta promotion was on Aug 26 and stable release was on Sep 21. 
We use CountDeprecation which sends deprecation reports automatically IIUC.

I don't see any decline.
 
Have we looked into which URLs are triggering this? (and if it's a few medium-sized properties or many tiny ones) 

I haven't looked at the data.
Did we try outreach?
No.

Mike West

unread,
Oct 28, 2021, 3:30:17 PM10/28/21
to Yutaka Hirano, Yoav Weiss, blink-dev
I think it's reasonable for us to dig into the data a little bit to determine whether the 0.04% number quoted above will result in user-facing breakage. Yutaka, is that something you'd be willing to dig into?

The direction seems philosophically correct to me, so I'd like to see it ship, but I'd also like to make sure we're not making the web worse for users by doing so.

-mike


Yutaka Hirano

unread,
Nov 1, 2021, 12:58:05 AM11/1/21
to Mike West, Yoav Weiss, blink-dev
Thank you for the feedback.

Do you have concrete steps for the investigation in your mind?

Yutaka Hirano

unread,
Nov 4, 2021, 7:54:30 AM11/4/21
to Mike West, Yoav Weiss, blink-dev
(friendly ping)

Chris Harrelson

unread,
Nov 4, 2021, 3:31:36 PM11/4/21
to Yutaka Hirano, Mike West, Yoav Weiss, blink-dev
Would it be feasible to get a random list of 10-20 sites that hit the use counter and see if they are broken badly by this feature?

Yoav Weiss

unread,
Dec 1, 2021, 6:11:49 AM12/1/21
to blink-dev, Chris Harrelson, Mike West, Yoav Weiss, blink-dev, Yutaka Hirano
Friendly ping on Chris' question

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yutaka Hirano

unread,
Dec 1, 2021, 10:00:06 AM12/1/21
to Yoav Weiss, blink-dev, Chris Harrelson, Mike West
Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.
Please note that this feature is related to authorization so it is likely to break things when signing in.


(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

Yoav Weiss

unread,
Dec 1, 2021, 10:29:57 AM12/1/21
to Yutaka Hirano, blink-dev, Chris Harrelson, Mike West
On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.
Please note that this feature is related to authorization so it is likely to break things when signing in.

So it's possible that the breakage only occurs for logged in users, and is not something you'd be able to see when spot checking their homepage?

Yutaka Hirano

unread,
Dec 2, 2021, 12:56:40 AM12/2/21
to Yoav Weiss, blink-dev, Chris Harrelson, Mike West
On Thu, Dec 2, 2021 at 12:29 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhi...@chromium.org> wrote:
Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.
Please note that this feature is related to authorization so it is likely to break things when signing in.

So it's possible that the breakage only occurs for logged in users, and is not something you'd be able to see when spot checking their homepage?
 
Yeah, I think so.

Mike West

unread,
Dec 8, 2021, 11:52:25 AM12/8/21
to blink-dev, Yutaka Hirano, blink-dev, Chris Harrelson, Mike West, Yoav Weiss
From my perspective, it's a bit worrying that you found user-visible breakage in a random sampling of the otherwise small number of sites that fall into this category. As Yoav suggested, there's some additional likelihood that we're not seeing some breakage that requires sign-in. It might be worthwhile to raise a deprecation warning for this behavior, and remove it after giving developers some time to adjust, perhaps with an enterprise policy for good measure. I'd be happy with a 3-release timeline, with removal thereafter. That might drive the usage down to the point where we can reasonably remove it. If it doesn't, we might need to do some more research (wiring this counter up to UKM, for instance) to see if we can track down more clear sources of potential breakage.

-mike

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yutaka Hirano

unread,
Dec 9, 2021, 6:17:40 AM12/9/21
to Mike West, blink-dev, Chris Harrelson, Yoav Weiss
We've been showing a deprecation message since 94. Sadly the deprecation message hasn't decreased the usage so far.

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

Yoav Weiss

unread,
Jan 5, 2022, 12:15:20 PM1/5/22
to blink-dev, Yutaka Hirano, blink-dev, Chris Harrelson, Yoav Weiss, Mike West
Hey Yutaka!

We discussed this at the API owners meeting today (Daniel, Chris, Alex, MikeT and myself).
It seems like the risk here is too high to remove support as is, and a reasonable next step may be to add the metric to UKM and get a more detailed view of which sites are using it and how. That would enable us to better assess breakage, and reach out to those sites to reduce current usage until potential breakage reaches acceptable levels.

One other question that came up: Is the usage related to developers adding the "Authorization" header on their own, or is it something the browser sends under certain circumstances? (e.g. when receiving 401 responses with "WWW-Autenticate" headers)
Would renaming the headers used in such authentication protocols be a useful alternative to consider? I'm guessing that doing that would require server changes as well, so won't necessarily help with cases of existing content, but may help to move newer auth flows to make safer CORS choices.

Cheers :)
Yoav

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yutaka Hirano

unread,
Jan 12, 2022, 10:41:39 AM1/12/22
to Yoav Weiss, blink-dev, Chris Harrelson, Mike West
Hi Yoav,

Thank you for the suggestions. I'll try to add UKM.

> One other question that came up: Is the usage related to developers adding the "Authorization" header on their own, or is it something the browser sends under certain circumstances? (e.g. when receiving 401 responses with "WWW-Autenticate" headers)

This is only for authorization headers set by scripts (via fetch() and XHR). Authorization headers the browser attaches are out of scope.

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

Chris Harrelson

unread,
Jan 26, 2022, 11:33:19 AM1/26/22
to Yutaka Hirano, Yoav Weiss, blink-dev, Mike West
Hi, just checking in on this intent. From the API owners' perspective, we're going to wait for the UKM, thanks.
Message has been deleted

Javier Garcia Visiedo

unread,
Jul 12, 2022, 11:18:42 PM7/12/22
to blink-dev, Chris Harrelson, Yoav Weiss, blink-dev, Mike West, Yutaka Hirano
Hi, 
I'm taking over this issue, currently writing the UKM collection review document. IIUC the ask is to opt in the existing use counter for the feature into a UKM. I was wondering (and sorry for the naive question) what would a UKM add to our research, over the existing counter? Or is the intention to add some other metrics to it? Thanks! 
Cheers
Javier

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yoav Weiss

unread,
Jul 13, 2022, 1:49:30 AM7/13/22
to Javier Garcia Visiedo, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
Hey Javier!

The benefits of UKM is that it can give us a list of URLs that have some breakage potential. The laternative is to cross the usecounter with HTTPArchive data, but that has a strong bias towards homepages, so may miss a lot of pages that require a login and are not the homepage. With a more accurate list of URLs, we'd be able to better assess the usage and potential breakage. 

Cheers :)
Yoav

On Wed, Jul 13, 2022 at 3:52 AM Javier Garcia Visiedo <vis...@chromium.org> wrote:
Hi,
I am starting a UKM collection review to opt in the existing use counter into an UKM. Sorry if my question is too naive, I just wanted to understand what benefits would the UKM add over the existing use counter? Or is it the intention to add additional metrics to it? Thanks!
Cheers
Javier


On Thursday, January 27, 2022 at 1:33:19 AM UTC+9 Chris Harrelson wrote:

Javier Garcia Visiedo

unread,
Mar 29, 2023, 1:51:26 AM3/29/23
to blink-dev, Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano, Javier Garcia Visiedo
Hi all,

Please find the summary of my findings, after analyzing the UKM data.

Currently, the UKM data shows 2,087 distinct domains (eTLD+1) sending a wildcard for ACAH and/or ACAO in response to a credentialled request. The UKM data is not good at showing events over time, but the use counter indicates the feature use is currently at 0.12% of total page loads, and the monthly average of page loads has been steadily increasing since the introduction of the use counter.

Out of the 2,087 domains found in the UKM, the top one accounts for 39.24% of the total navigations in the UKM (54% within top 20 sites), using this feature. The user experience is not visibly impacted for this site, as CORS is blocking calls to a publisher.Ads are displayed properly, so apparently the blocked calls are impacting some kind of targeted ads API. This site came into the data set for the first time in March 2023, and it’s very popular, so we expect to observe a big bump on the use counter from now on. This site is an outlier in terms of traffic volume, compared to other sites present in the UKM, and given the lack of Ux impact we decided to exclude it from the analysis presented below, to get a better representation for the rest of the sites.

Excluding the top site, we tested the next top 20 domains in number of navigations using this feature, accounting for 42% of the total navigation in the UKM. In addition to this, we sampled the long tail for 11 more sites randomly, for an additional 3,4% of the total navigation in the UKM.

Extrapolating data from the sampling, we classified sites in the following categories:

  • No Ux impact: 94.85% of the navigations are free from visible user experience impacts. In most cases, CORS policy is blocking calls to personalization or analytics APIs.

  • Impact to critical functionality, overall experience, log-in, etc.: 2.6%

  • Impact to ancillary elements being blocked by CORS policy, such as ads or widgets not essential to the overall page functionality: 2.55%

Putting these numbers in context of the total page loads reported by the use counter, 0,0062% of the total page loads experience some UX regression due to the introduction of this feature. Of these, 0,0031% was unusable.

We reached out to the site owners with Ux impacts, and we were able to confirm that 100% of the sites identified to have critical impact have already migrated out of this feature.

Happy to further clarify the data if needed.

Thanks
Javier

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yoav Weiss

unread,
Mar 29, 2023, 3:35:32 AM3/29/23
to Javier Garcia Visiedo, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
Thank you so much, Javier! :) That's some great analysis!

On Wed, Mar 29, 2023 at 7:51 AM Javier Garcia Visiedo <vis...@chromium.org> wrote:
Hi all,

Please find the summary of my findings, after analyzing the UKM data.

Currently, the UKM data shows 2,087 distinct domains (eTLD+1) sending a wildcard for ACAH and/or ACAO in response to a credentialled request. The UKM data is not good at showing events over time, but the use counter indicates the feature use is currently at 0.12% of total page loads, and the monthly average of page loads has been steadily increasing since the introduction of the use counter.

Out of the 2,087 domains found in the UKM, the top one accounts for 39.24% of the total navigations in the UKM (54% within top 20 sites), using this feature. The user experience is not visibly impacted for this site, as CORS is blocking calls to a publisher.Ads are displayed properly, so apparently the blocked calls are impacting some kind of targeted ads API. This site came into the data set for the first time in March 2023, and it’s very popular, so we expect to observe a big bump on the use counter from now on. This site is an outlier in terms of traffic volume, compared to other sites present in the UKM, and given the lack of Ux impact we decided to exclude it from the analysis presented below, to get a better representation for the rest of the sites.

Excluding the top site, we tested the next top 20 domains in number of navigations using this feature, accounting for 42% of the total navigation in the UKM. In addition to this, we sampled the long tail for 11 more sites randomly, for an additional 3,4% of the total navigation in the UKM.

Extrapolating data from the sampling, we classified sites in the following categories:

  • No Ux impact: 94.85% of the navigations are free from visible user experience impacts. In most cases, CORS policy is blocking calls to personalization or analytics APIs.


"CORS policy" here refers to the status quo before this feature ships?
 
  • Impact to critical functionality, overall experience, log-in, etc.: 2.6%

  • Impact to ancillary elements being blocked by CORS policy, such as ads or widgets not essential to the overall page functionality: 2.55%

Putting these numbers in context of the total page loads reported by the use counter, 0,0062% of the total page loads experience some UX regression due to the introduction of this feature. Of these, 0,0031% was unusable.

We reached out to the site owners with Ux impacts, and we were able to confirm that 100% of the sites identified to have critical impact have already migrated out of this feature.

That's a bit higher than what we're typically comfortable with, but it's great to hear that sites you reach out to react quickly.
How much of that impact was in the top 20 (where we can reasonably reach out) vs. the long tail (where it'd be significantly harder to communicate things beyond deprecation logs and reports)?

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

Javier Garcia Visiedo

unread,
Mar 29, 2023, 4:32:29 AM3/29/23
to blink-dev, Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano, Javier Garcia Visiedo
Thank you for your quick reply Yoav,

Please find my answers inline.


On Wednesday, March 29, 2023 at 4:35:32 PM UTC+9 Yoav Weiss wrote:
Thank you so much, Javier! :) That's some great analysis!

On Wed, Mar 29, 2023 at 7:51 AM Javier Garcia Visiedo <vis...@chromium.org> wrote:
Hi all,

Please find the summary of my findings, after analyzing the UKM data.

Currently, the UKM data shows 2,087 distinct domains (eTLD+1) sending a wildcard for ACAH and/or ACAO in response to a credentialled request. The UKM data is not good at showing events over time, but the use counter indicates the feature use is currently at 0.12% of total page loads, and the monthly average of page loads has been steadily increasing since the introduction of the use counter.

Out of the 2,087 domains found in the UKM, the top one accounts for 39.24% of the total navigations in the UKM (54% within top 20 sites), using this feature. The user experience is not visibly impacted for this site, as CORS is blocking calls to a publisher.Ads are displayed properly, so apparently the blocked calls are impacting some kind of targeted ads API. This site came into the data set for the first time in March 2023, and it’s very popular, so we expect to observe a big bump on the use counter from now on. This site is an outlier in terms of traffic volume, compared to other sites present in the UKM, and given the lack of Ux impact we decided to exclude it from the analysis presented below, to get a better representation for the rest of the sites.

Excluding the top site, we tested the next top 20 domains in number of navigations using this feature, accounting for 42% of the total navigation in the UKM. In addition to this, we sampled the long tail for 11 more sites randomly, for an additional 3,4% of the total navigation in the UKM.

Extrapolating data from the sampling, we classified sites in the following categories:

  • No Ux impact: 94.85% of the navigations are free from visible user experience impacts. In most cases, CORS policy is blocking calls to personalization or analytics APIs.


"CORS policy" here refers to the status quo before this feature ships?

No, these calls are blocked when activating the feature
 
 
  • Impact to critical functionality, overall experience, log-in, etc.: 2.6%

  • Impact to ancillary elements being blocked by CORS policy, such as ads or widgets not essential to the overall page functionality: 2.55%

Putting these numbers in context of the total page loads reported by the use counter, 0,0062% of the total page loads experience some UX regression due to the introduction of this feature. Of these, 0,0031% was unusable.

We reached out to the site owners with Ux impacts, and we were able to confirm that 100% of the sites identified to have critical impact have already migrated out of this feature.

That's a bit higher than what we're typically comfortable with, but it's great to hear that sites you reach out to react quickly.
How much of that impact was in the top 20 (where we can reasonably reach out) vs. the long tail (where it'd be significantly harder to communicate things beyond deprecation logs and reports)?

For sites with high impact (already addressed) 100% were found in the top 20. 
For sites where some visual elements are blocked, 55% (1.48% of total navigations registered in the UKM for this feature) are part of the top 20, 45% in the long tail, with 1.07% of total navigations in the UKM.


(friendly ping)



Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name



Blink componentBlink>SecurityFeature>CORS

TAG reviewNot needed because this implements an existing feature.

TAG review statusNot applicable


Risks


Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones.


Can you similarly send deprecation reports as well? How long have the deprecation messages been in place? Did we see any decline in the numbers?

We've shown the deprecation message since Chrome 94 whose beta promotion was on Aug 26 and stable release was on Sep 21. 
We use CountDeprecation which sends deprecation reports automatically IIUC.

I don't see any decline.
 
Have we looked into which URLs are triggering this? (and if it's a few medium-sized properties or many tiny ones) 

I haven't looked at the data.
Did we try outreach?
No.

We have an enterprise policy so that administrators can keep the existing behavior. We're planning to remove the policy on Chrome 103. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard



Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals


Debuggability

We'll show a CORS error to the devtools console.



Is this feature fully tested by web-platform-tests?Yes

Flag nameCorsNonWildcardRequestHeadersSupport

Requires code in //chrome?False (or, True only for the enterprise policy.)

Tracking bughttps://crbug.com/1176753

Estimated milestones

97


Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5742041264816128

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yoav Weiss

unread,
Mar 29, 2023, 5:02:08 AM3/29/23
to Javier Garcia Visiedo, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
On Wed, Mar 29, 2023 at 10:32 AM Javier Garcia Visiedo <vis...@chromium.org> wrote:
Thank you for your quick reply Yoav,

Please find my answers inline.


On Wednesday, March 29, 2023 at 4:35:32 PM UTC+9 Yoav Weiss wrote:
Thank you so much, Javier! :) That's some great analysis!

On Wed, Mar 29, 2023 at 7:51 AM Javier Garcia Visiedo <vis...@chromium.org> wrote:
Hi all,

Please find the summary of my findings, after analyzing the UKM data.

Currently, the UKM data shows 2,087 distinct domains (eTLD+1) sending a wildcard for ACAH and/or ACAO in response to a credentialled request. The UKM data is not good at showing events over time, but the use counter indicates the feature use is currently at 0.12% of total page loads, and the monthly average of page loads has been steadily increasing since the introduction of the use counter.

Out of the 2,087 domains found in the UKM, the top one accounts for 39.24% of the total navigations in the UKM (54% within top 20 sites), using this feature. The user experience is not visibly impacted for this site, as CORS is blocking calls to a publisher.Ads are displayed properly, so apparently the blocked calls are impacting some kind of targeted ads API. This site came into the data set for the first time in March 2023, and it’s very popular, so we expect to observe a big bump on the use counter from now on. This site is an outlier in terms of traffic volume, compared to other sites present in the UKM, and given the lack of Ux impact we decided to exclude it from the analysis presented below, to get a better representation for the rest of the sites.

Excluding the top site, we tested the next top 20 domains in number of navigations using this feature, accounting for 42% of the total navigation in the UKM. In addition to this, we sampled the long tail for 11 more sites randomly, for an additional 3,4% of the total navigation in the UKM.

Extrapolating data from the sampling, we classified sites in the following categories:

  • No Ux impact: 94.85% of the navigations are free from visible user experience impacts. In most cases, CORS policy is blocking calls to personalization or analytics APIs.


"CORS policy" here refers to the status quo before this feature ships?

No, these calls are blocked when activating the feature

Oh, ok. So these may have invisible breakage, that results in some ancillary service failure, but that users are unlikely to notice.
 
 
 
  • Impact to critical functionality, overall experience, log-in, etc.: 2.6%

  • Impact to ancillary elements being blocked by CORS policy, such as ads or widgets not essential to the overall page functionality: 2.55%

Putting these numbers in context of the total page loads reported by the use counter, 0,0062% of the total page loads experience some UX regression due to the introduction of this feature. Of these, 0,0031% was unusable.

We reached out to the site owners with Ux impacts, and we were able to confirm that 100% of the sites identified to have critical impact have already migrated out of this feature.

That's a bit higher than what we're typically comfortable with, but it's great to hear that sites you reach out to react quickly.
How much of that impact was in the top 20 (where we can reasonably reach out) vs. the long tail (where it'd be significantly harder to communicate things beyond deprecation logs and reports)?

For sites with high impact (already addressed) 100% were found in the top 20. 

That's very reassuring, thanks!

Yoav Weiss

unread,
Mar 29, 2023, 12:35:10 PM3/29/23
to Javier Garcia Visiedo, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
For these visual elements, are there any common threads that you could notice? E.g. Any common 3P providers?
I guess the same question also applies to the non-visual breakage. (you mentioned analytics and personalization providers)

Javier Garcia Visiedo

unread,
Apr 5, 2023, 5:54:23 AM4/5/23
to Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
For these visual elements, are there any common threads that you could notice? E.g. Any common 3P providers?

 In all cases I've seen, these are 1P requests of the form https://foo.example to https://api.foo.example/api/v1/blah. I've not found many sites with these visual element impacts, so I've been trying to contact them. So far with no luck.

I guess the same question also applies to the non-visual breakage. (you mentioned analytics and personalization providers)

These account for the majority of the cases I found, and all but 2 of them are 1P.

I have identified two cases of 3P which are quite relevant, and have just made contact with them. I will provide an update once I receive feedback.
 

Mike Taylor

unread,
May 15, 2023, 9:57:13 AM5/15/23
to Javier Garcia Visiedo, Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano

Hi Javier,

On 4/5/23 5:54 AM, Javier Garcia Visiedo wrote:

For these visual elements, are there any common threads that you could notice? E.g. Any common 3P providers?

 In all cases I've seen, these are 1P requests of the form https://foo.example to https://api.foo.example/api/v1/blah. I've not found many sites with these visual element impacts, so I've been trying to contact them. So far with no luck.

I guess the same question also applies to the non-visual breakage. (you mentioned analytics and personalization providers)

These account for the majority of the cases I found, and all but 2 of them are 1P.

I have identified two cases of 3P which are quite relevant, and have just made contact with them. I will provide an update once I receive feedback.
Any luck hearing back from these sites?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMFgMgw_1WzXH6ewDJQk3bKrz%3DwdPzUp%2B7vRDKpMzeRK%2B43%3DUw%40mail.gmail.com.

Javier Garcia Visiedo

unread,
May 16, 2023, 1:03:34 PM5/16/23
to Mike Taylor, Javier Garcia Visiedo, Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano
Yes, I've got a positive response from the two 3P APIs  (relatively popular). One case is already solved and in production, the second one, responsible for a huge increase on the UKM entries from February - March is solved and testing right now.

However, I believe we still want to coordinate the launch with other browsers. Discussions are ongoing in this sense, and so far Firefox confirmed they are in a similar situation, code complete and ready to ship if / when we are.  

Yoav Weiss

unread,
May 23, 2023, 7:07:42 AM5/23/23
to blink-dev, vis...@google.com, Javier Garcia Visiedo, Yoav Weiss, blink-dev, Chris Harrelson, Mike West, Yutaka Hirano, Mike Taylor
I'd be supportive of a coordinated change, given that popular 3P outreach was successful, and 1P use is unlikely to result in user visible breakage.
What's the timeline you have in mind? What's the outreach plan to make developers aware of this upcoming change?

--
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+unsubscribe@chromium.org.

Javier Garcia Visiedo

unread,
May 24, 2023, 4:48:10 AM5/24/23
to Yoav Weiss, blink-dev, vis...@google.com, Chris Harrelson, Mike West, Yutaka Hirano, Mike Taylor
I was targeting M116, which is aligned with what Firefox indicated. However, other browsers are yet to confirm their timeline, and they have indicated they might need more time, which makes 116 unrealistic if we want to get other browsers in addition to Firefox onboard. 

Regarding the outreach plan, we haven't discussed it in detail, but I imagine it'd be something like blog posts from each vendor, in addition to the existing warnings on the developer tools. 

I'll come back once I get more details from the remaining vendors. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

Yoav Weiss

unread,
Jul 19, 2023, 11:46:42 AM7/19/23
to Javier Garcia Visiedo, blink-dev, vis...@google.com, Chris Harrelson, Mike West, Yutaka Hirano, Mike Taylor
Any updates on this? :)

Javier Garcia Visiedo

unread,
Jul 21, 2023, 4:12:51 AM7/21/23
to Yoav Weiss, blink-dev, vis...@google.com, Chris Harrelson, Mike West, Yutaka Hirano, Mike Taylor
There is an ongoing conversation with Mozilla and Safari for the coordinated removal of wildcard support for ACAH. 

Firefox has this implemented behind a flag, same as we do, and we are waiting for Safari's plans at this point. 

Jason Robbins

unread,
Oct 4, 2023, 8:45:24 PM10/4/23
to blink-dev, vis...@chromium.org, blink-dev, Javier Garcia Visiedo, Chris Harrelson, mk...@chromium.org, Yutaka Hirano, mike...@chromium.org, yoav...@chromium.org
At this morning's API Owners meeting, they asked me to add all review gate types to all of the "web developer facing code change" features that are currently under review, including this one.  So, I have added Privacy, Security, Enterprise, Debuggability, and Testing gates to your feature entry. 

Please click the gate chips in the "Prepare to ship" stage on your feature detail page.  For each one, answer survey questions and request that cross-functional review.  You can request them all in parallel.  In cases where you already have the go/launch bit approved, you can note that in a comment on that gate for a potentially faster review.

Thanks,
jason!
Reply all
Reply to author
Forward
0 new messages