Multiple buckets

[annevk]

The simplest thing we could do for a v2 as @lukewagner suggested is introduce the ability for sites to mint new boxes that are either "atomic" or "persistent" (if they have permission).

There's two ways I see we could integrate with IDB and the Cache API. Either they have accessors on boxes or you pass a box when you create new instances of either IDB or Cache.

[bunneyster]

The Chrome team will potentially look into this issue some time in the near future, so I'm interested in learning of any general updates and if any new approaches have been considered, in order to gauge the scope of the issue and consider how we could collaborate. Thank you!

[annevk]

#71 is all I'm aware of. I think at a high-level Mozilla is still interested in evolving this space, but clearly it's not been a priority. One thing that comes to mind is that anti-tracking might warrant some additional consideration here. E.g., as trackers abuse first-party document.domain they might do similar for these APIs.

[asakusuma]

Having discrete buckets for storage would be really nice for clearing out storage.

1. It would potentially allow Clear Site Data to target a subset of the storage, reducing collateral damage during usage
2. Makes it easier to manage and prioritize storage when storage allocation is low

[wanderview]

I think @asutherland mentioned an interest in this topic to me recently.

[asutherland]

Yes, Firefox is interested in evolving how we do quota management and eviction, and allowing / strongly encouraging sites to use multiple buckets feels like a fundamental necessity. In particular, we'd like to move away from promising that an origin (well, rather, eTLD+1 group) can have 10% of the user's free disk space or 2GiB, whichever is smaller. If instead we could give a 10-100MiB quota and require that any additional usage beyond that has to happen in specifically named and evictable buckets, that would allow a much more sane and intentional eviction mechanism.

At the W3C Gaming Workshop, people expressed a lot of interest in this as well, however no one expressed any API exposure preferences.

Relatedly, I proposed WICG/background-fetch#135 as a sort of bridge to a multiple buckets future. The core idea is that downloads are an ambient, revocable UX prompting mechanism that avoids spamming the user with prompts they don't care about. It would be nice to align buckets with such a UX convention rather than having users always need to fall back to a "storage manager"-styled UX like Firefox exposes under about:preferences. (Even if users didn't pay too much attention to the downloads, I would hope it would bias sites to use human-readable names since it would add user confusion to their list of things for developers to worry about.)

[pwnall]

This presentation has the proposal discussed at TPAC 2019.

Next steps: figure out who will turn this proposal into an explainer and drive the spec process.
/cc @asutherland @dmurph @inexorabletash @spark008

[annevk]

One thing that would be good to do as part of this is making it clear in all existing APIs that they end up doing their storage transactions on a bucket that's selected via an origin.

Having that more explicit will help clarify how multiple buckets work and will help with anti-tracking efforts (and requestStorageAccess()) as they'll add another key on top of origin.