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

> Cool! Here are some further questions and thoughts:
> 
>     If a cross-origin iframe has a same-origin worker and that worker fetches something same-origin with From-Origin: same set, will it fail?

I have yet to add tests for workers but yes, it should fail.

>     Should we make same and same-site case-sensitive to be more similar to null and how we compare origins? (I'd suggest yes.)

You're saying the header has to say "Same" or "Same-Site," exactly so?

>     How do we deal with multiple From-Origin headers (either multiple or comma-separated)? We need to be clear on whether same, same-site or same, https://hello.example ends up being ignored or means something.

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.

>     I'd really like to include that referrer check pointed out above, but it seems a little contingent on being able to ship that for CSP/X-Frame-Options too. Perhaps we can try to be strict here first and if restricting it for CSP/X-Frame-Options fails we loosen this up? (It's also a little different as this always applies, whereas those only affect navigation.)

Did I miss something above? Can you explain what you're referring to? Thanks.

> Also, the way WebKit deals with "invalid" values means that if someone deploys From-Origin: https://hello.example today it'll never fail to load in WebKit until they add support for that. Perhaps it's better to be strict from the start here given that origins are best compared byte-for-byte (after splitting on comma and stripping HTTP whitespace)?

We thought about this and discussed it during code review. It comes down to supporting Same and Same-Site for the time being and maybe adding domain whitelisting down the road.

I would not like a header like "From-Origin: Same, compromised.com" to start off enforcing same-origin and then later open up for Spectre attacks from compromised.com two years later when browsers add domain whitelisting.

I want invalid headers to just fail so that what developers deploy today, keeps its functionality whatever we add to the header later. That said, I'm open to discuss.

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