Expose redirectCount for TAO opted-in redirect chains

[yoavweiss]

As part of the WebPerfWG discussion, we aligned Fetch's TAO definition to opt-in to the destination origin for navigations: whatwg/fetch#1931

This PR implements the HTML parts of using these new algorithms in order to resolve w3c/navigation-timing#215.

• At least two implementers are interested (and none opposed):
  • Chromium: Add TAO destination check for navigation redirect chains fetch#1931 (comment)
  • WebKit: Add TAO destination check for navigation redirect chains fetch#1931 (review)
• Tests are written and can be reviewed and commented upon at:
  • Navigation-Timing: destination-based TAO web-platform-tests/wpt#60823
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/521861828
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2049166
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=316647
  • Deno (not for CORS changes): N/A as it doesn't do navigations.
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A as it doesn't do navigations.
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A as this has no a11 implications.
• MDN issue is filed: Navigation Timing - Timing-Allow-Origin change mdn/mdn#841
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/document-lifecycle.html ( diff )
/infrastructure.html ( diff )

[annevk]

I don't understand how this works. What if one redirect allows it and one doesn't?

[yoavweiss]

I don't understand how this works. What if one redirect allows it and one doesn't?

I may have gotten this wrong, but I thought TAO check only passes if the entire redirect chain has Timing-Allow-Origin

[annevk]

No, TAO check only looks at a single response. There's https://fetch.spec.whatwg.org/#concept-response-timing-allow-passed but I don't actually know if that works well for navigations. Navigations are messy.

[yoavweiss]

I don't actually know if that works well for navigations.

A bit of Claude-assisted digging got me to:

• https://html.spec.whatwg.org/C#create-navigation-params-by-fetching (step 21.5) calls fetch with a "manual" redirect mode.
• https://fetch.spec.whatwg.org/#ref-for-fetch-controller-next-manual-redirect-steps%E2%91%A1 sets the next manual redirect steps to run HTTP-redirect fetch.
• https://html.spec.whatwg.org/C#create-navigation-params-by-fetching step 21.6 calls https://fetch.spec.whatwg.org/#fetch-controller-process-the-next-manual-redirect which calls the next manual redirect steps
• HTTP-redirect fetch calls main fetch, which runs the TAO check and sets the right timing-allow-passed value on the response.

So I think that simply changing the TAO check to looking at the response's timing-allow-passed value should work..

Let me know if you agree

[annevk]

Yeah that looks correct. I think there are still issues with it, but this is not one of them. There is still the question as to whether it's okay that same-origin redirects end up exposed without opt-in.

[yoavweiss]

There is still the question as to whether it's okay that same-origin redirects end up exposed without opt-in.

Yeah, I'll open a separate issue RE that

[yoavweiss]

There is still the question as to whether it's okay that same-origin redirects end up exposed without opt-in.

Yeah, I'll open a separate issue RE that

w3c/resource-timing#434

[yoavweiss]

As discussed yesterday on the WebPerfWG call (and as pointed out by @annevk elsewhere), this is not correct, as we'd need the navigation TAO to opt-in to the destination origin, rather than the source origin. I'll revamp.

[yoavweiss]

In w3c/navigation-timing#215 (comment) @achristensen07 suggests that we should also take the "noreferrer" values into account. This seems like we could add that condition here.

In the context of Fetch, I'm working on a PR to create navigation-specific TAO checks that look at the destination origin.

[yoavweiss]

In w3c/navigation-timing#215 (comment) @achristensen07 suggests that we should also take the "noreferrer" values into account. This seems like we could add that condition here.

Thinking about this, I think it makes sense. We can think of it as:

• The source navigation can opt-out of redirect timing (as it is the one choosing the redirectors) through noreferrer, or through Referrer-Policy.
• The redirector itself can opt-in to timing through TAO, based on the destination origin

[noamr]

As far as implementer support, Chrome team is supportive.

[annevk]

I think we should invert this. Start out with 0 and reveal the count if we're satisfied all conditions are met.

[yoavweiss]

I think we should invert this. Start out with 0 and reveal the count if we're satisfied all conditions are met.

Done!

[annevk]

Looks good modulo one more nit. Thanks for tackling this!