Friendly ping! :) Any news on UKM data here? On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav Weiss wrote:
> Sounds great, thanks!! :) > > On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi <[email protected]> > wrote: > >> Hi Yoav, >> >> Sorry I haven't sent an update in this thread. (1) sounds reasonable. I >> added the usercounters to UKM a few weeks ago and I'm waiting for data. I >> will report back after manual inspections are done. >> >> Thanks, >> >> >> On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss <[email protected]> wrote: >> >>> 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/683c2acb-bc01-4ab5-b18b-a2048f059693n%40chromium.org.
