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/CABihn6G9n9JrTEsih6SeTa%2Bf25Btx_g0gWSFrOGwoe8EE5yhdg%40mail.gmail.com.
