Re: [whatwg/fetch] Proposal: `Sec-Site` should capture information about the requester of a resource (#700)

> Is there any room in this proposal for including the type of request (corresponding to the "AS script" etc in other specs).

I know I've talked to @arturjanc about this, and I do support it. I don't think I've written that down anywhere, though, so, there you are. :) Encoding the initiator and destination of the request in a way the server can access would be really interesting, and I can see real use cases for it from a security perspective.

I think origin manifests are a bit off topic, but:

> As for Origin Policy, I think folks had thoughts on removing the statefullness somehow, but no progress has been made recently. The draft as it stands today is known not to work for Safari.

I don't think there's any tweaking around the edges that we can do to make origin manifests not represent state in third-party contexts. Regardless of explicit advertisement of the manifest version in HTTP request headers, the mechanism will certainly support some features that will create web-visible state for a given origin: that's the whole point of the feature. :) As a silly example, consider a manifest that sets a `script-src https://1.example.com` as a baseline for an origin, and a page that attempts to load `https://1.example.com/js` and `https://2.example.com/js`. If a user wishes to separate their first-/third-party state, browsers will need to separate the origin manifests as well.

> if we can make it work without gating on Origin Policy I would also prefer that.

I don't see this as at all related to origin manifests, except insofar as origin manifests might be a reasonable configuration mechanism if we decide that this should be opt-in. I'm not sure the size overhead is enough to care about, but it's a debate worth having.

-- 
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/700#issuecomment-381870513