Re: [whatwg/fetch] Add usage advice for Sec- (PR #1818)

johannhof left a comment (whatwg/fetch#1818)

> There will always be judgment involved. Our discussion about the proposed `Sec-`-prefixed fields for storage access headers highlights that.

Martin, respectfully, it's a bit strange to point to a discussion in which you yourself, citing your proposed model from this PR, question the `Sec-` prefix, as proof that it's a matter of judgement.

> But the meaning of those words is clear: if the server depends on the value coming from the browser because it is making a decision that might have unwanted consequences if something other than a browser didn't produce it -- which also implies that there are credentials or something else in the request that is relevant to that decision and that also could only possible come from a browser -- then we have a reason to apply the prefix.

I'm sorry, how is this clear? How do you objectively define "a decision that might have unwanted consequences" and "relevant to that decision"? With this policy, we would need to maintain a secondary list of both the types of decisions we consider vulnerable and the types of "something else" that we consider impacting those decisions.

> Is there an alternative set of criteria that you would have apply in deciding when `Sec-` applies?

To quote from my comment just before this one:

> One origin should just not be able to manipulate state that another origin expects to receive from the user agent, like permission state.

Again, I believe we can apply judgement in making exceptions to this rule, but we should not discourage usage of `Sec-` by default.

I understand that there may be valid concerns against `Sec-`, so let's talk about those and how to mitigate them, but arguing that the SOP is a too strict rule and we should rather follow some rough guideline is really the wrong angle to approach it from.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1818#issuecomment-2829053722
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1818/c2829053722@github.com>