search

privacycg / storage-access-headers

Proposal for HTTP headers related to the Storage Access API
https://cfredric.github.io/storage-access-headers/
Creative Commons Attribution 4.0 International
27 stars 2 forks source link

The "Sec-" prefix is unnecessary #17

Closed sjledoux closed 1 month ago

sjledoux commented 1 month ago

Taken from this comment:

We find the use of the Sec- prefix to be unnecessary. Sites presently receive requests with and without cookies. That a new signal might elicit new and inappropriate reactions from a server is possible, but not a particularly credible one. Denying web applications the option to elicit one more inappropriate action using this mechanism is wasteful.

cfredric commented 1 month ago

CC @jyasskin since he wrote the original feedback, in case he can provide more color.

Denying web applications the option to elicit one more inappropriate action using this mechanism is wasteful.

It's not clear to me what is being "wasted", in the TAG's view. If the TAG is concerned about the bytes on the wire, we could omit the "Sec-" prefix but still make the header name "forbidden", thereby saving 4 bytes. But this doesn't change any semantics, so it doesn't address the "denying web applications the option..." part of the TAG's feedback. Therefore I don't interpret the TAG's concern to be about saving those 4 bytes.

Therefore, I think the concern is about the semantics. However, I don't see an argument for allowing web applications to send inappropriate values. I'm not aware of any security, privacy, or usability concerns that are alleviated by allowing that usage, and the TAG didn't provide any.

Given that I also don't see any cost to making the header name forbidden, and I do see possible security issues that are mitigated by making the header name forbidden, I think there's no harm in doing so.

Tentatively closing; please reopen or comment if needed.

jyasskin commented 1 month ago

@martinthomson can elaborate more, but I believe his concern is mostly about the 4 bytes: if there's no real risk from websites setting the header, it's wasteful to make the header name longer than it needs to be.

cfredric commented 1 month ago

As stated in the explainer, IMHO there is a risk from websites setting the header. A malicious site could set the value to be "active", and mislead some 3P server into thinking that it had already assessed the request's security context (i.e. the embedding frames or the Origin header), and therefore mislead the server into allowing something security-sensitive.

However, either way, the Sec- prefix is not necessary for being a forbidden header name; we can just add to the list in step 1 of https://fetch.spec.whatwg.org/#forbidden-request-header. But before considering that, I'm interested in seeing the concrete problems that step 2 in that algorithm has caused; and learning why step 2 exists in the first place if it's considered a high-cost for new headers.

johannhof commented 1 month ago

Maybe I'm making this up but isn't the point behind Sec- also that it's a reserved namespace which makes adding new headers easy because we don't have to worry about backwards compatibility?

I genuinely think it would be helpful for TAG to publish a position on adding new headers on the web and naming them, taking into considerations things like header compression, known server-side incompatibilities, etc.

johannhof commented 1 month ago

And I agree with Chris that it's important that "the user agent remains in full control" (to cite Fetch) of the SAH, for security reasons.