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

[arichiv]

I'd like to propose the adoption of Extending Storage Access API (SAA) to non-cookie storage by the Privacy Community Group.

This work is being prototyped in Chrome as of today and was discussed at TPAC 2023.

Summary of Proposal:

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.

Browsers currently shipping the Storage Access API apply varying methods of when or how to ask the user for permission to grant 3p cookie access to a site. Given that this proposal involves extending the existing Storage Access API, while maintaining largely the same implications (from a privacy/security perspective) to the user, a consistent prompt for cookie and non-cookie access is preferred. No prompt is needed when the origins are RWS (Related Website Sets, the new name for First Party Sets).

[johannhof]

See prior discussion at privacycg/storage-access#102

To address the potential question of "shouldn't we continue to do this work in the Storage Access API repository?", I'd like to say from an editor's perspective that we'd prefer to "freeze" the scope of current spec work on SAA to what's shipping in browsers today and only fix bugs and integration with cookies to allow for graduation into HTML. Outsourcing new proposals into their own work items under Privacy CG makes sense to me.

cc @annevk @bvandersloot-mozilla to correct me if this doesn't match their view

[annevk]

I think I’d be pretty flexible for smaller proposals. Really depends on how much ends up needing to fundamentally change. (And if we somehow manage to not get cookie integration done we might have to reconsider as well, but I’m optimistic we can do it based on our progress thus far.)

[johannhof]

@privacycg/chairs I think this got generally positive reception at the last call, any concerns with adopting this?

[martinthomson]

The chairs need to confer on this one, but it looks like we have the requisite interest.

[arichiv]

Proposed IDL: https://github.com/arichiv/saa-non-cookie-storage/blob/main/idl.md

Chrome OT launched in M120 for some parts, the rest are coming in M121.

[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.

Let's discuss this at the next Privacy CG meeting.