Sending Sec-Fetch-Storage-Access: none on every cross-origin request seems wasteful

[ricea]

I cannot see any user benefit to sending

Sec-Fetch-Storage-Access: none

on every cross-origin request. Since the server is required to treat the absence of the header as none, it would be more efficient to just not send it at all.

[HeikoTheissen]

Sec-Fetch-Storage-Access: none is very different from the absence of the Sec-Fetch-Storage-Access header.

If you execute

fetch("https://httpbin.org/response-headers?Set-Cookie=a=b;SameSite=None;HttpOnly;Secure",
{credentials:"include"})

in a browser console while visiting https://stackoverflow.com,

• the request has Sec-Fetch-Storage-Access: none
• the Set-Cookie response header is ignored by the browser (because of third-party cookie blocking).

If you execute the same command while visiting https://httpbin.org

• the request has no Sec-Fetch-Storage-Access header
• the Set-Cookie response header is honored by the browser.

If the server treated absence and none as equivalent it would be blind to this difference in browser behavior.

[ricea]

But the absence of Set-Fetch-Storage-Access could mean any of:

• The request is same origin
• The browser doesn't implement Storage Access Headers
• The user hasn't disabled third-party cookies.

It doesn't seem like a reliable enough signal to be useful.

[HeikoTheissen]

In all three cases, the server can send an (unpartitioned) cookie and be sure that the browser will honor it. That is the signal I expect from the absence of the Sec-Fetch-Storage-Access header.

[cfredric]

The main reason for sending something on cross-site requests (and not omitting the header entirely) is to indicate that the browser supports this feature (and therefore would have sent inactive or active if there were any way to use cross-site cookies in this context).

I.e., the presence of none indicates that setting an unpartitioned cookie will definitely fail; whereas the absence of any header value means that the server cannot infer anything about whether an attempt to set an unpartitioned cookie would fail or succeed. Servers need some kind of signal that conveys that info, because we should not assume that all browsers will implement this feature (and all clients will update, etc.).

I'm open to other suggestions here; are there better methods for doing feature detection for HTTP-based features?

[cfredric]

@johannhof and I went back to the drawing board a bit on this, but we're still confident that sending none explicitly is necessary. The explainer text focuses on the active and inactive states, but from partner conversations we have received strong feedback that a clear, unambiguous signal that third-party cookies are blocked is also essential.

If we omit none, we see the following issues:

• It's no longer possible to distinguish a same-site context (where cookies might be allowed) from a cross-site context (where cookies might be blocked) without the introduction of another signal like Define Sec-Fetch-Frame-Ancestors. w3c/webappsec-fetch-metadata#89 (which would be more metadata on the wire anyway).
• We also find that the semantics of this feature would be harder to explain to developers, and harder to convey how to use the feature properly.

On the surface, it seems that omitting none would be most interoperable with other browsers that block third-party cookies and don't support SAH, because the default state in those browsers is equivalent to none. But this breaks down in situations where those browsers would allow cookies, e.g. through a storage-access permission grant (or even a same-site context), since the Sec-Fetch-Storage-Access: active header would not be present.

Closing this issue for now, but feel free to follow up if you have more thoughts.