Meta: export keys, sheds, and bottles

[domenic]

Closes #162 by superseding it. /cc @jyasskin. (I was going to encourage that to get merged and then do mine on top, but then I saw that the CI was stalled for some reason, which I didn't want to make you bother to figure out.)

webmachinelearning/writing-assistance-apis#47 will use "storage key" and "storage bottle", if you're curious. It sounds like privacycg/nav-tracking-mitigations#37 wants to use "storage sheds".

---

Preview | Diff

[annevk]

So the idea was that external specifications would only need "obtain a local storage bottle map" and "obtain a session storage bottle map".

It seems that for various reasons dependencies are taken on parts I thought of as private, which might be fine, but then maybe we should make that more explicit somehow.

[jyasskin]

@MrPickles to discuss the use of storage sheds from https://privacycg.github.io/nav-tracking-mitigations/#clear-non-cookie-storage-for-host. Looking at that, it's possible the call site should actually move into Storage as a higher-level operation.

[inexorabletash]

See also #153

A slight tangent, but if there's a general rethink on what should be exported: both Indexed DB and Web Locks use (or should use) storage keys and bottles in ways beyond the original idea. In both of those cases, it's because the bottle map idea is a great fit for the local storage API (it's a simple key/value store) but for more complex cases there are some contortion required to make it fit; there's more logic required to managing IndexedDB's set of databases and the set of requested/held Web Locks than just entries in a map. One approach is to say that a site's entire "indexeddb manager" or "lock manager" resides in a single value within the local session storage bottle map for "indexeddb" or "lock", but that also feels kinda weird.

[annevk]

One approach is to say that a site's entire "indexeddb manager" or "lock manager" resides in a single value within the local session storage bottle map for "indexeddb" or "lock", but that also feels kinda weird.

I think that would be okay though. But I suppose we could abstract it differently in that a bottle holds a value and the map is something we stick there for sessionStorage and localStorage...

[MrPickles]

@MrPickles to discuss the use of storage sheds from https://privacycg.github.io/nav-tracking-mitigations/#clear-non-cookie-storage-for-host. Looking at that, it's possible the call site should actually move into Storage as a higher-level operation.

The current use case of storage sheds within the BTM spec is to delete all storage for a given host. Intuitively, abstracting that behavior into the storage spec seems reasonable to me.

However, there may be future spec changes around conditionally partitioning storage for a site. It's currently in an explainer and nothing is finalized yet, but I can imagine the possibility of direct manipulation of storage sheds in such a scenario.

[domenic]

I'm glad to have started this discussion, as I suspected these might be intentionally internal.

I'll note that my case is pretty different from the more complicated ones suggested above: I'm just referencing these concepts in semi-normative "privacy consideration" sections. Here's a representative sample:

The simplest [privacy mitigation] is to treat model downloads like all other stored resources, including them in a [=storage bottle=] which is partitioned by [=storage key=]. This lets the origin model's existing privacy protections operate and obviates the need for anything more complicated. The downside is that this spends more of the user's time, bandwidth, and disk space redundantly downloading the same model across multiple sites.

A slight variant of this is to re-download the model every time it is requested by a new [=storage key=], while re-using the on-disk storage. This still uses the uesr's time and bandwidth, but at least saves on disk space.

Going further, a user agent could attempt to fake the download for new [=storage keys=] by just waiting for a similar amount of time as the real download originally took.

I'd be curious if you have advice for this sort of text. Should we just say these concepts without linking to them? Should we try to use more vague language so as not to depend on these concepts existing, if they're actually considered internal implementation details?

[annevk]

Using slightly vaguer language seems preferable for such a use case. That will make refactoring easier.

[domenic]

OK. But can we at least export "storage key"? It's weird that we export "obtain a storage key" and "obtain a storage key for non-storage purposes", but nobody can refer to their return types.

[annevk]

I could find no reason why we didn't do that when we introduced it so I made that change in #180 along with some minor cleanup.

[domenic]

Great, thank you!