Any plans for local storage access API as a part of Storage Access API?

[alexuaua]

Hi,

Loading extensions in an iframe is used by many cloud-based apps, just to name online version of Microsoft Office or Google Workplace, and an app inside iframe needs a way to persist state and login information. Popular identity authentication platforms like Firebase Authentication or auth0 rely on local storage or indexedDB. Another big difference vs cookies is the size of data one can store (with local storage it's possible to save data user works on, even if a connection goes offline, and restore later).

Mozilla Web Docs describes the API as

a way for embedded, cross-origin content to gain unrestricted access to storage that it would normally only have access to in a first-party context (we refer to this as an origin’s first-party storage).
and also
requestStorageAccess() Returns a Promise that resolves if the access to first-party storage was granted, and rejects if access was denied.

But WebKit notes operate on first-party cookies vs first-party storage:
WebKit implementation notes

So unless the Storage Access API was built only as a "Cookies Access API", are there any plans to offer a local storage access with API? I may be missing some privacy issues caused by local storage or IndexedDB vs cookies for a user who explicitly (requestStorageAccess) granted access to a "storage" (I'd really appreciate if someone can point out. Except for expiration, but this is already covered by "30 days"), but so far I've seen a lot of office, educational, BI web-apps with recommendation to turn off the "prevent cross site tracking" feature due to lack of a storage access API for storage purposes.

[annevk]

#31 tracks this. Firefox is currently leaning towards aligning with Safari on this and restricting this API to cookies. There are some intractable problems with unpartitioning storage unfortunately. In a future where we have https://github.com/WICG/storage-buckets unpartitioning (a subset of) storage might become more realistic.

cc @artines1

[alexuaua]

@annevk thank you for commenting and for providing the link to a future description.
I'd really appreciate if you could point if there is a discussion on the problems with storage, to my understanding I'm not the first affected, but I probably used wrong search terms or places.

The distinct storage buckets scheme always seemed logical for me but wouldn't (while I'm probably missing something) the same scheme could be used to provide partitioned storage for a "TLD + iframe" combination - this looks similar in preventing cross-site tracking (iframe domain loaded as top page would see different bucket vs in iframe, iframe loaded under another TLD would see yet another bucket, and additionally a user still needs to explicitly allow an app in iframe inside specific TLD grant a permission), but at the same time allowing to use web-apps with plugins and extensions (iframe is still the only way to isolate third-party content and there are tons of apps that greatly benefit from plugins/extensions).

[annevk]

#4 and privacycg/storage-partitioning#9 go into them to some extent. I'd say the main problem is service workers. Part of the issue here too is that not partitioning storage is also becoming a security problem.

[johannhof]

I think this is actually a dupe of #102 so I'll close it as that, though correct me if I'm wrong.