On Wed, Mar 29, 2023 at 11:01 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > 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. >> > 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) > >> >> 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/CAL5BFfUKG0v5o0LdwiS_uQBsbJ4%2BMO02iKvYKnj-s5SAJMWSPg%40mail.gmail.com.
