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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> (friendly ping) >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano < >>>>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>>>> 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 < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano < >>>>>>>>>>>>>>>> [email protected]> 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 [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>>>>>> 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 [email protected] >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> >>>>>>>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVV%3DsLc4BtXVKz1p%2B0iM%3D7wBbik8W7Ym8crM5ynP-CkRA%40mail.gmail.com.
