Adopt Storage Access Headers and unify top-level-storage-access permission with storage-access permission

[aselya]

We propose to deprecate the CORS integration with rSAFor and switch to an access model based on the original SAA permission instead, utilizing Storage Access Headers for cross-site resources embedded in the top-level page. This will help improve the security posture of the API and allow for the unification of top-level-storage-access permission with storage-access permission.

Why?

Reason 1: CORS is not the right security mechanism for Storage Access

When rSAFor was first designed, CORS was the best security mechanism available that enabled a per-request opt in. Since rSAFor was developed, Storage Access Headers (SAH) have been launched. SAH directly addresses the security concerns that are not mitigated by CORS through requiring an opt-in from the embed before it receives a credentialed request. Another concern with CORS is that it grants access to cross-origin reads, which are not strictly required for Storage Access. As such, a website using it for rSAFor might expose unnecessary attack surfaces.

Reason 2: Unification of top-level-storage-access and storage-access permission

Unlike cookies made accessible through storage-access permission, cookies made accessible through top-level-storage-access required credentialed CORS requests to be made available. Because of this difference, it made sense to have two separate permissions to help communicate to developers when cookies would be made available. If CORS is replaced with SAH as the security mechanism for storage access, then cookies that were previously only made available through top-level-storage-access would also be eligible for storage-access permissions. Having two permissions that allow the same underlying behavior and are granted by the same mechanism is superfluous.

Here’s what we think we should do concretely:

Deprecate top-level-storage-access permission
This has several consequences:
Cookies that previously would have been granted top-level-storage-access permission by rSAFor will be granted storage-access permission instead
There will no longer be a requirement to use CORS credentialed requests to send cookies made accessible by top-level-storage-access permission
Top-level-storage-access permission will no longer be queriable by navigator.permissions.query()
Update rSAFor spec to reflect the deprecation of top-level-storage-access permission
Change the return of rSAFor to result in a promise that always resolves but does not reveal information about the state of the storage-access permission of the embed
Storage-access permission state has only been queryable by the embed. Exposing it through the return of rSAFor will provide information about the embed that has not been exposed previously.

The changes that are being proposed are not backward compatible and so we do expect to have some deprecation period for affected sites.

I’ve filed the following PRs for this change, and will add more as necessary.
Update explainer to unify storage access permissions and replace CORS with storage access headers
Remove CORS dependency and integration with the permissions.query() method

There is still an open question for us:
Should the call to rSAFor still return if storage access was granted or should it just resolve without returning information about the result of the call to the caller as we are proposing?