Allow all storage types to expire, not just cookies

[davidsgrogan]

I could imagine this being done at the box level.

I've heard this requested a few times over the years but the presented use cases escape me at the moment. @inexorabletash might remember.

[inexorabletash]

I believe it was a privacy/authentication concern. E.g. a mail service may expire auth credentials via cookies after 30 days, and for privacy reasons they'd also want to wipe offline/cached data as well.

[annevk]

Yeah, there was an idea to set an expiry thingie on a box so you can do this kind of thing.

[annevk]

I guess if we want this before we want boxes we could add something dedicated for the default box.

[jakearchibald]

The requests I've heard around this are more granular. Eg restrict a particular cache/objectStore to a particular size or number of items.

[annevk]

@jakearchibald that's different from letting it expire, no? But that's a feature we could also have with named boxes.

[jakearchibald]

Here's the related SW issue w3c/ServiceWorker#863

[indolering]

Chiming in from a mention on StackOverflow asking for input. Client-side storage amounts to a data cache and automatically expiring data would reduce boilerplate code and lead to more efficient use of storage.

[Krinkle]

Client-side storage amounts to a data cache and automatically expiring data would reduce boilerplate code and lead to more efficient use of storage.

See also https://phabricator.wikimedia.org/T121646#3063515 which described the same from a downstream perspective.

Lack of any reasonable eviction mechanism (LRU, TTL, etc.) for localStorage is proving difficult to deal with at scale.

[indolering]

Yikes, I hadn't thought about this:

This means that when our more active users that participate on multiple wikis (Wikimedia hosts over 800 wikis, including 284 active Wikipedia subdomains), you visit a wiki, even once, that module cache is populated, but until you visit that wiki again, we have no way to clear it. The modules may have changed many times since then, and would be pruned immediately when viewed, but still it's taking up precious space and preventing other wikis from claiming space instead (in Firefox).

[annevk]

FWIW, on IRC @Krinkle asked for expiration at the key-value level. While this could be emulated with lots of boxes, that might not be efficient nor desirable. @Krinkle if that's still desirable perhaps you could go into the use cases a bit why all these keys might need different expiry times?

[NotherGithubAccount]

Not entirely sure if this is the right place to chime in, but just in case: We use indexeddb to buffer map data for a browser game. The game is organized in rounds on different subdomains, each of which will shut down at some point, when players will no longer visit the map and buffered data will needlessly persist. We're talking up to a couple of hundred MB each.

As such, +1.

[alshdavid]

Likewise, I am using indexeddb as a buffer cache for a context that might be visited again but likely won't be (I cannot use a service worker in this case) and will be hundreds of megabytes, potentially gigabytes.

Currently the browser will persist the data indefinitely however it would be ideal if I could set an expiry on a key so it could remove itself if it has not been accessed within that time.