Expose redirectCount for TAO opted-in redirect chains

[yoavweiss]

Fixes w3c/navigation-timing#215

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
• 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.