On Wed, Mar 29, 2023 at 10:32 AM Javier Garcia Visiedo <visi...@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 < > visi...@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 > <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. > > > "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! > 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. > > > 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 > > Specificationhttps://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# > 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 > <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 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+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/CAL5BFfUS_DDkFYbtyF2gFh8hFOWXaqSq_Y9UEimSnR8ZYm6QAQ%40mail.gmail.com.
