Friendly ping on the above :) Does (1) sound reasonable from your perspective?
On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss <[email protected]> wrote: > The way I see this, given that the usecounter is an order of magnitude > higher than what we can consider trivial, we have 3 options: > 1) Add the usecounters to UKM > <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounters%20ukm&ss=chromium>, > run an analysis on early data to extract URLs that use this, and randomly > sample those for manual inspection. > 2) Wait for the HTTPArchive crawl to run with this usecounter, assuming > that unauthed landing pages will trigger it. > 3) Run an HA query that tries to find cross-origin redirects with Auth > headers. I'm not sure how easy (or feasible) that would be, but Rick and > Pat would know > > To me, (1) seems to be the easiest, and with the least amount of potential > bias (all pages vs. unauthed landing pages). > > On Tue, Mar 14, 2023 at 9:45 PM Patrick Meenan <[email protected]> > wrote: > >> Do we expect the Authorization header to be something that the HTTP >> Archive triggers in a way that the feature will trigger? Since they are >> all unauthenticated single page loads, it feels like it's unlikely to be >> something that we hit. >> >> On Tue, Mar 14, 2023 at 4:37 PM Patrick Meenan <[email protected]> >> wrote: >> >>> Looks like the feature flag was added Feb 16 >>> <https://chromium-review.googlesource.com/c/chromium/src/+/4235597> which >>> looks like it should have made the 112 branch point >>> <https://chromiumdash.appspot.com/schedule>. If we hold the April >>> crawl back a couple of days and start it on the 4th after stable is >>> released then we can pick it up in April, otherwise it would show up >>> mid-crawl. >>> >>> On Tue, Mar 14, 2023 at 4:24 PM Rick Viscomi <[email protected]> >>> wrote: >>> >>>> Am I reading the feature page >>>> <https://chromestatus.com/feature/5195900413018112> correctly that >>>> it'll land in stable version 113? If so, HTTP Archive wouldn't pick that up >>>> until the May crawl. >>>> >>>> cc @Patrick Meenan <[email protected]> to keep me honest >>>> >>>> On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> It's possible that we need to wait for the next HA run to get actual >>>>> examples. >>>>> +Rick Viscomi <[email protected]> would know.. >>>>> >>>>> On Mon, Mar 13, 2023 at 12:28 AM Kenichi Ishibashi <[email protected]> >>>>> wrote: >>>>> >>>>>> Thank you Yoav for the suggestion. I couldn't find sample URLs from >>>>>> the HTTPArchive data (feature usage >>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470>). >>>>>> I'll add a feature flag to prepare for reverting this change if breakage >>>>>> is >>>>>> problematic. >>>>>> >>>>>> On Fri, Mar 10, 2023 at 7:06 PM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> One option to tighten the potential for breakage would be to e.g. >>>>>>> sample 10 URLs that are hitting that usecounter (e.g. from the >>>>>>> HTTPArchive >>>>>>> data), and test them manually to see how many of them would break once >>>>>>> this >>>>>>> change is applied. Based on the number you'd get, we can estimate the >>>>>>> magnitude of breakage we can expect to see in the wild. >>>>>>> Another option would be to roll this out with a base feature flag >>>>>>> (that we'd want anyway) and be ready to revert if breakage is more than >>>>>>> we'd like. >>>>>>> >>>>>>> Combining those two options is probably safest. >>>>>>> >>>>>>> On Fri, Mar 10, 2023 at 8:51 AM Kenichi Ishibashi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Use counter reports 0.022%. My guess is that most usage happens >>>>>>>> accidentally but we are not sure. >>>>>>>> >>>>>>>> API owners, should we do a reverse OT? >>>>>>>> >>>>>>>> On Fri, Feb 17, 2023 at 9:38 AM Kenichi Ishibashi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Quick update, we added a use counter to see how often this >>>>>>>>> could happen. I'll get back once we have data. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 8, 2023 at 11:51 PM Yoav Weiss <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Any use counters on how often this happens? >>>>>>>>>> >>>>>>>>>> On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 Kenichi >>>>>>>>>> Ishibashi wrote: >>>>>>>>>> Contact [email protected] >>>>>>>>>> >>>>>>>>>> Specificationhttps://fetch.spec.whatwg.org/#http-redirect-fetch >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> Remove Authorization header on cross origin redirects to scope a >>>>>>>>>> developer-controlled Authorization header to the origin of the >>>>>>>>>> initial >>>>>>>>>> request. >>>>>>>>>> >>>>>>>>>> Blink componentBlink>Loader >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>>>>>>>> >>>>>>>>>> TAG review >>>>>>>>>> Not applicable, the spec has been already updated. >>>>>>>>>> https://github.com/whatwg/fetch/pull/1544 >>>>>>>>>> >>>>>>>>>> TAG review statusNot applicable >>>>>>>>>> >>>>>>>>>> Risks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interoperability and Compatibility >>>>>>>>>> >>>>>>>>>> Low. All browser vendors agreed with this change. >>>>>>>>>> >>>>>>>>>> *Gecko*: Shipping (https://bugzilla.mozilla.org/ >>>>>>>>>> show_bug.cgi?id=1802086) >>>>>>>>>> >>>>>>>>>> Do we know if they ran into any compat issues when shipping this? >>>>>>>>>> >>>>>>>>> None I'm aware of. I checked the bug and related issues in GitHub >>>>>>>>> but I didn't find anything. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_ >>>>>>>>>> bug.cgi?id=230935) Historically Safari always removed >>>>>>>>>> Authorization headers even for the same origin redirects. Recently >>>>>>>>>> the >>>>>>>>>> behavior has changed to preserve them on same origin redirects. >>>>>>>>>> >>>>>>>>>> That's encouraging in terms of lack of potential reliance on >>>>>>>>>> these headers. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Web developers*: No signals >>>>>>>>>> >>>>>>>>>> *Other signals*: >>>>>>>>>> >>>>>>>>>> WebView application risks >>>>>>>>>> >>>>>>>>>> N/A >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debuggability >>>>>>>>>> >>>>>>>>>> Web Developers can use DevTools network panel to see the actual >>>>>>>>>> request headers. >>>>>>>>>> >>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>> Yes >>>>>>>>>> >>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ?Yes >>>>>>>>>> https://wpt.fyi/results/xhr/xhr-authorization-redirect. >>>>>>>>>> any.html?label=master&label=experimental >>>>>>>>>> https://wpt.fyi/results/fetch/api/credentials/ >>>>>>>>>> authentication-redirection.any.html?label=experimental >>>>>>>>>> >>>>>>>>>> Flag nameNot applicable >>>>>>>>>> >>>>>>>>>> Requires code in //chrome?False >>>>>>>>>> >>>>>>>>>> Tracking bughttps://bugs.chromium.org/p/ >>>>>>>>>> chromium/issues/detail?id=1393520 >>>>>>>>>> >>>>>>>>>> Estimated milestones >>>>>>>>>> >>>>>>>>>> M112 >>>>>>>>>> >>>>>>>>>> Anticipated spec changes >>>>>>>>>> >>>>>>>>>> The spec has been already updated. >>>>>>>>>> >>>>>>>>>> https://github.com/whatwg/fetch/issues/944 >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> https://chromestatus.com/feature/5195900413018112 >>>>>>>>>> >>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>> >>>>>>>>> -- 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/CAL5BFfVYVPKT6ob5T0h6KB1yRiycbB2fRjyN%2BqyeoYMDbHS-Rg%40mail.gmail.com.
