Define terminology for a site's storage with various kinds of keys

[jyasskin]

The storage of a top-level frame is keyed by just its origin, while storage for a subframe is keyed by at least its own origin and the top-level origin. Intuitively, we often talk about the situation of being keyed by just one origin as having access to "first-party storage", but that's not really defined anywhere, and I don't know of shared terminology for subframes' keying situation.

This explainer should say how other specifications should describe the various situations. It should probably also eventually define ways for other specifications to define the storage access of their own environment settings objects, but that seems farther away.

[annevk]

If by site's storage you mean the various storage APIs, I recently created https://storage.spec.whatwg.org/#model for that which also has the concept of a storage key. At the moment it's an origin, but it gives us a single point to change it for all current and future APIs.

whatwg/storage#93 abstracts this out a bit more so it can also be used by BroadcastChannel and such.

(whatwg/storage#88 is also relevant here.)

[jyasskin]

It's tough to follow the changes when they're scattered across this repository and various PRs in other repositories. 😉

The "shed"/"shelf" terminology is useful, but even once a "storage key" is defined as a list of origins or a (site, origin) pair, or similar, it seems like we're going to still need to distinguish between the shelves for (site, origin-within-that-site) vs the shelves for (site, cross-site origin), at least for the purpose of requestStorageAccess(). This issue was meant to request terminology for that distinction. I could imagine coining "first-party shelf" and "third-party shelf" for it?

[annevk]

This repository mostly serves as a bridge to those other repositories.

I see, we recently added partitioned and non-partitioned data to https://privacycg.github.io/storage-access/ though maybe they should end up in the Storage Standard long term.

[annevk]

This is probably no longer needed as departitioning of storage will not be a thing.