So this makes a storage access grant only apply to a single origin, rather than the entire site?

Yes and no. This makes the storage access grant be initially "active" only for the origin of the document that called document.requestStorageAccess(), rather than the entire site. But if another origin needs to access cookies, it can use document.requestStorageAccess() itself (which will resolve without a user gesture or a prompt), or activate the permission a different way (e.g. Storage Access Headers).

The effect of this is to keep the privacy boundary the same (i.e. keyed on <site, site>), but restrict the security model to be origin-based rather than site-based. So, one origin's use of SAA doesn't make the other origins of the site vulnerable.

Let me clarify: it makes document.requestStorageAccess() only apply to the origin of the document?

I'd be more comfortable with this if there were a positive signal from Apple around Storage Access Headers, because this further leans on that feature for subresources.

I agree that we should fix the cross-origin-same-site navigation fetch to not send unpartitioned cookies, however the subresource fetch inside of the document is the part that leans on Storage Access Headers.

Let me clarify: it makes document.requestStorageAccess() only apply to the origin of the document?

document.requestStorageAccess() will still request a permission that applies to the whole site, but only the document's origin is opted-in and receives cookie access as a result of the call. Other origins have to explicitly activate the permission by calling document.requestStorageAccess() themselves, if they also need cookie access.

if there were a positive signal from Apple around Storage Access Headers

FWIW, Anne wrote that SAH seems like a reasonable extension of Storage Access, and opened one issue about worker support (specifically for the Activate-Storage-Access: load header). He didn't mention any concerns about the Activate-Storage-Access: retry; ... part, which is what this would lean on. That's not a formal positive signal, though, to be fair.

I agree that we should fix the cross-origin-same-site navigation fetch to not send unpartitioned cookies, however the subresource fetch inside of the document is the part that leans on Storage Access Headers.

Are you saying that you'd expect SAA's Fetch integration to treat navigation fetches and subresource fetches differently? My assumption was that SAA's usage of Fetch would be agnostic to the request's destination, so that fetches of different kinds of resources get the same kind of CSRF protection (whether it's a navigation or not); i.e., whether cookies are included wouldn't depend on what exactly the page is fetching. WDYT?

Other origins have to explicitly activate the permission by calling document.requestStorageAccess() themselves, if they also need cookie access.

So they would need to create another iframe to do that (excepting SAH for subresources)?

Are you saying that you'd expect SAA's Fetch integration to treat navigation fetches and subresource fetches differently?

Yeah, that is the way I was thinking. In my mind you are fetching resources that are going into a different context than the current one, so it is natural to treat them as the destination context rather than the source context.

The way I'm thinking about this is like this. The storage access API breaks open the (sub)document to use its unpartitioned cookies. An iframe provider controls security by dictating what Origins can request the API. We permit the same-origin self-initiated navigations to persist the openness to allow document fetches out of convenience to developers without relaxing the security model.

So they would need to create another iframe to do that (excepting SAH for subresources)?

That's right. The principle is that if an origin didn't opt into cross-site cookie access, then the browser doesn't send cookies to it. And the two ways of opting in are:

• Call document.requestStorageAccess() in a document which is same-origin with the server endpoint that wants to receive cookies.
• Use SAH.

Yeah, that is the way I was thinking. In my mind you are fetching resources that are going into a different context than the current one, so it is natural to treat them as the destination context rather than the source context.

I think that model might be okay from a privacy POV, but not from a web security POV. From a security POV, we need to consider the source of the fetch too.

IMO this is easiest to see if we start by thinking about cross-site fetches: we know that when a malicious site can send unfettered credentialed requests to another site, it can carry out CSRF attacks. Whether the fetch is a navigation, or just a subresource fetch, doesn't matter w.r.t. CSRF.

But the web security model is the Same-Origin Policy, so the web's security principals are origins, not sites. So we can modify the CSRF attack (s/site/origin/g): a malicious origin should not be able to send credentialed requests to another origin. (At least not without that origin's prior go-ahead -- CORS' ACAC header is prior art here.)

This PR aims to achieve that protection -- at least whenever the SAA is the mechanism by which cookies are accessible.