Sec-Fetch-Ancestors?

[mikewest]

@davidben pointed out that we made a decision in Fetch Metadata to send the site-relationship between the initiator and the target in Sec-Fetch-Site, which doesn't allow servers to make the same decisions as we make with SameSite cookies, which send the relationship between the initiator and all its ancestors and the target. Perhaps we should add another header containing this relationship, which would allow servers to unifiy the declarative logic of SameSite with server-side logic around other characteristics of a request?

/cc @arturjanc @lweichselbaum @ckerschb WDYT?

[mikewest]

That is, A nested in A would send the following when making a request to A: Sec-Fetch-Site: same-origin and Sec-Fetch-Ancestors: same-origin. A nested in B would send the following when making a request to A: Sec-Fetch-Site: same-origin and Sec-Fetch-Ancestors: cross-site.

[mikewest]

(Note that this is somewhat similar to @deian, et al's Sec-Frame-Same-Origin proposal, but with some details shifted: it would be an enum value, like Sec-Fetch-Site, and it would be sent for every request, specifically including subresources, which seems necessary for servers to replicate the behavior of SameSite cookies)

[annevk]

Precedent in naming: X-Frame-Options, frame-ancestors, ancestorOrigins (disputed and not shipped in Firefox), window.frameElement, window.parent, window.top.

I would expect Frame in the name here.

[mikewest]

Sure: Sec-Fetch-Frame-Ancestors: whatever to match CSP?

[deian]

I'd love to see this!

[arturjanc]

Sounds reasonable to me as well. I like the consistency with Sec-Fetch-Site and also the fact that this would allow developers to better test upgrading their cookies to SameSite.

@mikewest For a top-level navigation, would it make sense to set Sec-Fetch-Frame-Ancestors: none? This could map to the strict vs. lax distinction, i.e.:

• Sec-Fetch-Frame-Ancestors: cross-site on some of your requests means you will potentially break if you set your cookie as SameSite
• Sec-Fetch-Frame-Ancestors: same-origin / same-site or (Sec-Fetch-Frame-Ancestors: none and Sec-Fetch-Site of same-origin / same-site / none) means that you can set SameSite=Strict
• Sec-Fetch-Frame-Ancestors: none and Sec-Fetch-Site: cross-site means you need to have SameSite=Lax because strict may break.

I haven't really thought this through, and perhaps we're already getting most of this information from Sec-Fetch-Site: none, but site=none could also be sent by some non-webby non-top-level requests, so having this value in Sec-Fetch-Frame-Ancestors seems potentially useful.

[mikewest]

Hrm. I started typing something else, but this might actually be a reasonable proposal... It would match CSP's semantic of frame-ancestors 'none', which is a nice property. I know we can't trivially implement it this way in Chrome, but it wouldn't be too terrible, I think.

[lweichselbaum]

+1 I like the idea and how well it fits into existing semantics of CSP and SameSite cookies.

[mikewest]

I started poking at this again between meetings over the last few weeks. I still think it's a reasonable thing to add to the platform, and it seems to be more interesting to more developers these days given the partitioning story for storage, etc.

I took a stab at one formulation of details in #89. I'd appreciate thoughts there about how we should handle various cases (top-level navigations stand out, but there are likely other interesting edges to test).