Hi, I'm taking over this issue, currently writing the UKM collection review document. IIUC the ask is to opt in the existing use counter <https://chromestatus.com/metrics/feature/timeline/popularity/3873> for the feature into a UKM. I was wondering (and sorry for the naive question) what would a UKM add to our research, over the existing counter? Or is the intention to add some other 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/238bd806-314a-4282-ac80-8b47454eda6dn%40chromium.org.
