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):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (not for CORS changes): …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

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

---

Preview | Diff

[noamr]

Chrome team is supportive.

[noamr]

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

[yoavweiss]

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

[noamr]

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.