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 Statushttps://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/CAL5BFfV3-%2Br40xya841f_hOV9ncR%2B%3Dr2zOsCMWy_9VVcKzK1fw%40mail.gmail.com.

Reply via email to