- From: John Wilander <notifications@github.com>
- Date: Fri, 27 Apr 2018 11:16:23 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/687/385052297@github.com>
> The problem with not allowing granular control in From-Origin is that it will be impossible for developers whose resources are loaded cross-site to use the header, even if they fully control the requesting domain. Given that headers such as X-Frame-Options are often set globally for the entire application, this means that developers who have any resources that fall into this category will either see their sites break or will have to manually exempt some resources from From-Origin, which will complicate adoption and reduce the security value of using the mechanism in the first place. > > Arguably, the sites that would benefit the most from From-Origin protections are the ones with large userbases, hosting sensitive authenticated content, which often have relatively complex cross-origin loading relationships. It seems to me there'd be a lot of value in making From-Origin work for them, or, if we decide against it, provide another mechanism they can use. Could a combination of referrer and From-Origin same/same-site achieve the same level of flexibility? I.e. if you get no referrer, you send a From-Origin header. I guess not since the referrer conveys nothing about frame ancestors. -- 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/687#issuecomment-385052297
Received on Friday, 27 April 2018 18:16:45 UTC