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

[privacycg]

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

[martinthomson]

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

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

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