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

[arichiv]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Extending Storage Access API (SAA) to non-cookie storage
• Specification or proposal URL (if available): https://privacycg.github.io/saa-non-cookie-storage/
• Proposal author(s) (@-mention GitHub accounts): @arichiv @johannhof
• Bugtracker URL: https://crbug.com/1484966
• Safari Position: Extending Storage Access API (SAA) to non-cookie storage WebKit/standards-positions#262
• TAG: Extending Storage Access API (SAA) to non-cookie storage w3ctag/design-reviews#906

Other information

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.

[zcorpan]

@asutherland

[asutherland]

@bvandersloot-mozilla (StorageAccess is primarily a privacy/anti-tracking concern).

[bvandersloot-mozilla]

See the original discussion and Privacy CG proposal.

There is no privacy concern here. Unpartitioned storage offers no benefit to attackers over unpartitioned cookies. Instead the question is whether the API is reasonable. @asutherland and @annevk offered varying degrees of pushback on localStorage and sessionStorage because they are sync.

I believe this proposal resolves @asutherland's concerns though. This call returns a handle, rather than trying to use storage buckets. Each storage type is opt-in, making it a developer choice if it is acceptable to degrade performance. But, it may be worth a second look.

[asutherland]

I'm generally happy with the consensus direction we ended up with in privacycg/storage-access#102 through the current timestamp.

The API described in the proposed solution seems consistent-ish with that but I would like to see the proposal expanded on, especially in terms of the semantics of "all" which was not/has not yet been discussed on privacycg/storage-access#102. Specifically, I can see an advantage to developers of being able to say "I want all the new storage API endpoints that show up in the future too", but it would be nice then to be sure that something like { all: true, localStorage: false } works so that developers can get the benefit of "all" but without incurring the cost of LocalStorage.

I know it's frequently explicitly discouraged for people to put WebIDL in explainers, but since Blink seems to be at the prototyping stage already, it likely does make sense to have some draft WebIDL and spec language around the relationship to the Storage spec's endpoint terminology.

[arichiv]

I agree that 'all' has tenuous value, to some extent it's there for developers who are testing or prefer convenience. I'm not sure I like the idea of an 'all, except for' feature. Developers who aren't into the convenience of 'all' should probably just be requesting the specific APIs they want.

I agree about WebIDL, if/once the explainer is adopted by the PrivacyCG I plan to put up a PR to modify the existing spec: https://privacycg.github.io/storage-access/.

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