Sec-Fetch-Site for script-based redirects

[arturjanc]

It's a common pattern to redirect to another URL by assigning to window.location in JS, as opposed to emitting a 302 response with a Location header -- it's useful if the redirecting endpoint is static.

This could be a concern for navigation restrictions because an attacker could use such a redirect to launder cross-origin navigations through such a redirector to make them appear as same-origin.

I wonder if we could tackle this case by treating script-based redirects which happen immediately after page load as another element in the redirect chain and update the site value of the resulting navigation using the algorithm for HTTP redirects from https://mikewest.github.io/sec-metadata/#redirects. This would probably require setting an arbitrary (short) time window after page load -- if the navigation happens within that time window, we'd consider it to be a redirect and update site accordingly.

An alternative is to just document this behavior and tell developers they should implement open redirects with HTTP. FWIW I don't think it's a large problem, but it will come up as developers start using the site value to restrict navigations.

[jerryzz0]

Just a note for completeness that this also applies to redirection via HTTP REFRESH as well. Notably, it's typical for JS redirectors to include <meta http-equiv="refresh" ... > as fallback for cases where JS is disabled.