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

Something in this space seems like a good idea, so I'm supportive of the general direction.

I wonder, though, whether it would be simpler to build on existing primitives rather than add a new header. For example: what if we started sending an `Origin` header with every request? Presumably, servers that would opt-into sending a `From-Origin` header would also be capable of blocking requests with unexpected `Origin` headers before passing the requests on to applications that might be damaged? (FWIW, I've also been toying around with the idea of sending a lower-granularity `Origin` header as part of some future authentication primitive, which would boil down to an enum of `cross-site`/`same-site`/`same-origin`).

`From-Origin` is potentially simpler to deploy for some endpoints that expect same-site usage, but always sending an indication of a request's provenance gives servers a lot of flexibility in how they deal with incoming requests. Since they're already dealing with that header for access control in general, relying upon it more broadly might be less overhead than creating a new primitive for the same purpose.

> To further complicate things, eTLD+1 has many names:

On this point in particular, I'd suggest that we'd be well-served to follow the PSL's ["registered domain"/"registrable domain" terminology](https://publicsuffix.org/list/), or to follow the "site" terminology that [`SameSite` cookies defines](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.2), that Chrome's "Site Isolation" uses, etc. I don't believe the other terms listed above are as commonly used, but I'm happy to just agree on some spelling of the concept and putting it into a more easily-referencable document.

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