Re: [whatwg/fetch] Enforce CORP on "navigate" request mode (#1113)

I don't think I like the idea of CORP applying to frames for the following reasons:
1. There are already two overlapping mechanisms that control embeddability (`X-Frame-Options` and `frame-ancestors`), and this would add a third one. CORP was explicitly designed as a complement to these mechanisms that applies only in `no-cors` mode, rather than as a general embedding control that would subsume them -- expanding its scope this way would be a significant design change after it already shipped.
2. Bundling embedding and subresource controls makes the adoption of CORP more difficult. With this change, if you wanted to set CORP of `same-site` application-wide, you'd also disallow framing, which may not be what you want (and this is also backwards-incompatible for sites that already enabled CORP).
    - I guess we could come up with some inheritance logic where CORP only applies if the site fails to set `X-Frame-Options` or `frame-ancestors`, but this is complicated and doesn't solve the problem of XFO being ignored on redirects.

IMHO a better avenue here is to fix the handling of XFO on redirect responses and/or update the MDN page about CORP to tell developers they should set `X-Frame-Options` application-wide, which is already a best practice. Otherwise, given that the concern here is limited to browsers without OOPIFs, I don't think it's a good long-term approach to change the semantics of CORP (especially assuming browsers need to ship OOPIFs anyway because they can't depend on developers enabling CORP everywhere).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1113#issuecomment-732228127