Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple buckets #2

Open
annevk opened this issue May 5, 2015 · 7 comments
Open

Multiple buckets #2

annevk opened this issue May 5, 2015 · 7 comments
Labels

Comments

@annevk
Copy link
Member

@annevk annevk commented May 5, 2015

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.

@annevk annevk added the later label Mar 31, 2016
@spark008
Copy link

@spark008 spark008 commented Jun 19, 2019

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
Copy link
Member Author

@annevk annevk commented Jun 20, 2019

#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.

@annevk annevk changed the title Multiple boxes Multiple buckets Jun 20, 2019
@asakusuma
Copy link

@asakusuma asakusuma commented Jun 21, 2019

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
Copy link
Member

@wanderview wanderview commented Jul 10, 2019

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

@asutherland
Copy link
Collaborator

@asutherland asutherland commented Jul 10, 2019

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
Copy link
Contributor

@pwnall pwnall commented Sep 26, 2019

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
Copy link
Member Author

@annevk annevk commented Sep 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

6 participants