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 <https://chromestatus.com/metrics/feature/timeline/popularity/3873> 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 On Wednesday, July 13, 2022 at 2:49:30 PM UTC+9 Yoav Weiss wrote: > 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 < > visi...@chromium.org> wrote: > >> Hi, >> I am starting a UKM collection review to opt in the existing use counter >> <https://chromestatus.com/metrics/feature/timeline/popularity/3873> 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: >> > Hi, just checking in on this intent. From the API owners' perspective, >>> we're going to wait for the UKM, thanks. >>> >>> On Wed, Jan 12, 2022 at 7:41 AM Yutaka Hirano <yhir...@chromium.org> >>> wrote: >>> >>>> 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. >>>> >>>> On Thu, Jan 6, 2022 at 2:15 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> 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 >>>>> >>>>> On Thursday, December 9, 2021 at 12:17:40 PM UTC+1 Yutaka Hirano wrote: >>>>> >>>>>> We've been showing a deprecation message since 94 >>>>>> <https://chromiumdash.appspot.com/commit/9a817d69a132822ddf2954120e96a3efa2290071>. >>>>>> >>>>>> Sadly the deprecation message hasn't decreased the usage so far. >>>>>> >>>>>> On Thu, Dec 9, 2021 at 1:52 AM Mike West <mk...@chromium.org> wrote: >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> On Thursday, December 2, 2021 at 6:56:40 AM UTC+1 Yutaka Hirano >>>>>>> wrote: >>>>>>> >>>>>>>> On Thu, Dec 2, 2021 at 12:29 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhir...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry for the delay! >>>>>>>>>> >>>>>>>>>> I checked 10 sites. I saw console errors in three sites among >>>>>>>>>> them: >>>>>>>>>> 1. https://cchatty.com/ >>>>>>>>>> 2. https://techrxiv.org/ >>>>>>>>>> 3. https://bodyshake.com/ >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Dec 1, 2021 at 8:11 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Friendly ping on Chris' question >>>>>>>>>>> >>>>>>>>>>> On Thursday, November 4, 2021 at 8:31:36 PM UTC+1 Chris >>>>>>>>>>> Harrelson wrote: >>>>>>>>>>> >>>>>>>>>>>> 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? >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Nov 4, 2021 at 4:54 AM Yutaka Hirano < >>>>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> (friendly ping) >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano < >>>>>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for the feedback. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you have concrete steps for the investigation in your mind? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Oct 29, 2021 at 4:30 AM Mike West <mk...@chromium.org> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Oct 21, 2021 at 12:04 PM Yutaka Hirano < >>>>>>>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss < >>>>>>>>>>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano < >>>>>>>>>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> (The implementation CL >>>>>>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3226283> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> is under review. This intent is written as if it's landed.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Contact emailsyhir...@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 componentBlink>SecurityFeature>CORS >>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> <https://chromiumdash.appspot.com/commit/9a817d69a132822ddf2954120e96a3efa2290071> >>>>>>>>>>>>>>>> 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#AuthorizationCovered >>>>>>>>>>>>>>>>>> ByWildcard >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>>> ?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 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+unsubscr...@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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails >>>>>>>>>>>>>>>> from it, send an email to >>>>>>>>>>>>>>>> blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EqkidJF3mjfnztmMnKrEpb%3DPTvW-kpW0s_bWCM%3DOXY8A%40mail.gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EqkidJF3mjfnztmMnKrEpb%3DPTvW-kpW0s_bWCM%3DOXY8A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ac61dfcd-2922-4834-8c64-8870855d0155n%40chromium.org.
