> > 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. On Thu, Mar 30, 2023 at 1:35 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > > > 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/CAMFgMgw_1WzXH6ewDJQk3bKrz%3DwdPzUp%2B7vRDKpMzeRK%2B43%3DUw%40mail.gmail.com.
