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?

[sunetzacharias]

We are rolling this out in production in the coming days, and it seems to be only within Chrome this is fully supported. As such we are reaching out to you and Mozilla.

Is there a timeline for this?

We are SeamlessAccess, a discovery service supporting research and higher education which covers metadata from an interfederation consisting of more than 5000 IdPs.

We offer a persistence service to store IdP metadata in a way that can be shared among Service Providers SPs, so that a choice of IdP to login to some SP can be reused to login to a different SP without needing to go through the discovery process again. This is implemented as an iframe with origin in a SeamlessAccess domain that interacts with the embedding SP pages through message events, and stores the metadata in localStorage.
With partitioned storage we will be forced to use the SAA to access non-partitioned storage and provide the persistence service, but the amount of data we need to store will typically not fit in a cookie.

You can see it in action with the Storage Access API tooling here use.thiss.io

[annevk]

Colleagues and I discussed this some more and we can probably get over sessionStorage and localStorage being included, despite not particularly liking it. There are some other issues that need addressing though:

• Declaring constructors as methods is strange privacycg/saa-non-cookie-storage#31
• "Return the result of running sessionStorage." privacycg/saa-non-cookie-storage#36

[johannhof]

Thanks Anne. Yeah, I think we've been letting these issues sit for a bit longer than necessary. We'll prioritize addressing them.