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. On Mon, May 15, 2023 at 10:57 PM Mike Taylor <miketa...@chromium.org> wrote: > 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? > > > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMFgMgw_1WzXH6ewDJQk3bKrz%3DwdPzUp%2B7vRDKpMzeRK%2B43%3DUw%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/0333ba45-d1e2-8afe-0431-0d6254d794e0%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0333ba45-d1e2-8afe-0431-0d6254d794e0%40chromium.org?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/CAFM5ELVyBsoan8Yq0JAeFmxcJNhyVWMwh-NyVbMuYPiFr%3D%2B0Sg%40mail.gmail.com.
