Extending Storage Access API (SAA) to non-cookie storage

[arichiv]

Title of the spec

Extending Storage Access API (SAA) to non-cookie storage

URL to the spec

https://privacycg.github.io/saa-non-cookie-storage/

Issue Tracker URL

https://crbug.com/1484966

TAG Design Review URL

w3ctag/design-reviews#906

Mozilla standards-positions issue URL

mozilla/standards-positions#898

Description

We propose an extension of the Storage Access API (backwards compatible) to allow access to unpartitioned (cookie and non-cookie) storage in a third-party context, and imagine the API mechanics to be roughly like this (JS running in an embedded iframe):

// Request a new storage handle via rSA (this should prompt the user)
let handle = await document.requestStorageAccess({all: true});
// Write some cross-site localstorage
handle.localStorage.setItem("userid", "1234");
// Open or create an indexedDB that is shared with the 1P context
let messageDB = handle.defaultBucket.indexedDB.open("messages");

The same flow would be used by iframes to get a storage handle when their top-level ancestor successfully called rSAFor, just that in this case the storage-access permission was already granted and thus the rSA call would not require a user gesture or show a prompt, allowing for “hidden” iframes accessing storage.

[annevk]

This is being proposed to the Privacy CG at privacycg/proposals#41 and was previously discussed in the context of the Storage Access API in privacycg/storage-access#102.

In the latter thread Andrew Sutherland and I pushed back against offering the soft-deprecated synchronous I/O APIs, localStorage and sessionStorage, through this new mechanism. Those comments haven't gotten a considered response as far as I can tell.

cc @sysrqb @johnwilander

[johannhof]

Thanks Anne!

In the latter thread Andrew Sutherland and I pushed back against offering the soft-deprecated synchronous I/O APIs, localStorage and sessionStorage, through this new mechanism. Those comments haven't gotten a considered response as far as I can tell.

I think I did give the response that once LocalStorage moves from "soft-deprecated" (whatever that means, I can see no indication of a deprecation or even discussion of the drawbacks of LocalStorage on MDN, for example) to "actually deprecated" SAA should follow that same deprecation strategy. As it stands, use of these two APIs is way too high to consider not including them (anecdotally, we've gotten a bunch of requests for LocalStorage support but none for IndexedDB).

[arichiv]

It's important to note that in the proposed API localStorage or sessionStorage would have to be requested to be included. They are offered, but one could just request access to unpartitioned indexedDB if they wanted.

[arichiv]

Two additional explainers (each of which is an extension to Storage Access API (SAA) to non-cookie storage) have been published!

Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies
The current Storage Access API requires that unpartitioned cookie access is granted if any unpartitioned storage access is needed. This forces unpartitioned cookies to be included in network requests which may not need them, having impacts on network performance and security. Before the extension ships, we have a chance to fix this behavior without a compatibility break.

Explainer: Extending Storage Access API (SAA) to Shared Workers
There has been increasing developer and implementer interest in first-party workers being available in third-party contexts the same way that third-party cookies already can be. In the absence of such a solution, we leave developers without a robust way to manage cross-tab state for frames loading the same origin. This explainer proposes a solution for developers to regain third-party access to Shared Workers in select instances to avoid user-facing breakage in browsers shipping storage partitioning.

Would it be possible to get review on this issue of those as well?