Re: [whatwg/fetch] From-Origin (#687)

> I'm still not convinced we need whitelisting of individual domains but maybe we do. It just feels like it'll be CSP all over again. Too complex => low adoption. With just Same and Same-Site, it's simple, kind of like XFO and HSTS, which I believe have seen significantly more adoption than CSP.

Without getting into a full post-mortem of CSP deployment difficulties, I think origin-based source lists are one of CSP's more understandable aspects, so I wouldn't look to them as the reason for low adoption.

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. 

> As for error handling, I think either way you open yourself up to problems later. The advantage of failing closed I think is that it's noticed sooner. And if invalid values due spread (as they seem to do for headers), it'll be hard later to enforce a byte-for-byte comparison as many loads will start failing at that point.

As someone who is interested in adopting `From-Origin`, I think I prefer John's current model of failing open on invalid values because it reduces the potential for breakage. For example, if any browser ships `From-Origin` without granular origin controls, then developers who need these granular controls will not be able to use them in supporting UAs because it will break functionality for users of the stricter browser. This would mean developers would need to do UA-sniffing, which would significantly increase the complexity of their server-side code (particularly because many frameworks set response headers via a static config.)



-- 
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-385048931