Add TAO destination check for navigation redirect chains

[yoavweiss]

As part of the WebPerfWG discussion on re-exposing redirectCount for opted-in cross-origin redirects, we discussed the fact that TAO currently only opts-in "backwards" in terms of origins, and doesn't constitute an opt-in to the destination origin, which is the appropriate opt-in for navigations (contrary to subresources).

This PR adds the mechanisms that can enable such "forward" opt-in, and can enable a response to a redirect chain to know that the redirect chain opted in to expose the redirects to its origin.

Once this lands, we'd use the relevant algorithms in the related HTML PR.

• At least two implementers are interested (and none opposed):
  • Chromium: Add TAO destination check for navigation redirect chains #1931 (comment)
  • WebKit: Add TAO destination check for navigation redirect chains #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.
• 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.)

---

Preview | Diff

Chrome team is supportive.

Wouldn't it be simpler to keep a list of TAO value sets and iterate over them when computing the "navigation TAO check"?

Wouldn't it be simpler to keep a list of TAO value sets and iterate over them when computing the "navigation TAO check"?

@annevk made a similar comment earlier on.

What we can do is something like:

• We need the end response of the chain to have a list of lists of all the TAO values each response seen. We can get that by adding the a list of lists of past values to the redirect request and then move it to the response.
• Navigation TAO check would verify that the TAO values of each response contain "*" or destination origin, otherwise it'd fail.

I don't know that it's simpler (and it seems like we'd be copying more values around between redirect responses), but happy to move to that model if that's simpler/easier

Wouldn't it be simpler to keep a list of TAO value sets and iterate over them when computing the "navigation TAO check"?

@annevk made a similar comment earlier on.

What we can do is something like:

• We need the end response of the chain to have a list of lists of all the TAO values each response seen. We can get that by adding the a list of lists of past values to the redirect request and then move it to the response.
• Navigation TAO check would verify that the TAO values of each response contain "*" or destination origin, otherwise it'd fail.

I don't know that it's simpler (and it seems like we'd be copying more values around between redirect responses), but happy to move to that model if that's simpler/easier

It's simpler to read (IMO) and potentially cleaner impl wise as there is no set manipulation as you go along and it's not a dedup check for each redirect.

LGTM (though needs the checkboxes etc)

@annevk - Can you take a look? Do I need to file a WebKit position on this, or will you be able to state support here?

This design seemed reasonable to @achristensen07 and I so you can consider WebKit supportive.

This looks good from the Mozilla side as well.