Default bucket durability questions

[quisquous]

In the context of w3c/IndexedDB#50, Chrome currently uses strict durability by default for idb transactions and Firefox uses relaxed durability by default. I'm curious about:

• the choice of strict by default for the default bucket
• the choice of relaxed by default for user-created buckets

What's the reasoning for behaving differently in these cases?

Is it expected that user agents that have different defaults ignore these defaults (e.g. Firefox continues to be relaxed for idb from the default bucket by default)?

[evanstade]

Good question.

Buckets will be used by developers who are extra conscious about performance since it's mainly about making it less likely for important data to get evicted. The biggest motivation for creating/using a non-default bucket would be to store temporary-ish data that the app can recover from not having. Thus I think the default of relaxed for user created buckets makes sense.

What should the default bucket behavior be? Either choice is arguable --- do developers with less time/knowledge to consider every option want something more reliable or more performant out of the box? It seems as though the choice for the default bucket as specified in the explainer was chosen to match the Chromium default for IDB. It might be hard or weird for FF to match that given the IDB default there. Perhaps the wording should be updated to make the default bucket's durability unspecced, or that it should match the user agent's default IDB behavior.

@ayuishii wdyt?

[ayuishii]

I agree, explicitly speccing as strict seems like it wouldn't be ideal for other user agents. Also seems like something we'd like to change as our default anyway https://crbug.com/965883#c9. I think I like the idea of updating the wording to match the user agent's default IDB behavior. Although I'm not sure if this means that we would need a default enum similar to IndexedDB.

@asutherland do you have any thoughts on default durability control behavior?

[asutherland]

I agree that Firefox would like to maintain our current IDB behavior and that we wouldn't want the default bucket to conflict with that. Also I think that there are a number of advantages to leaving the default bucket's behavior effectively unspecified (or specified as at the whim of user agents), including motivating use of buckets to get clarity around behavior by content authors.

Given that there's a durability() async getter and it seems like the "default" bucket can be opened, it seems like we probably need the "default" enum, but it would be quite reasonable to forbid its use for creation for any bucket other than the automatically created "default" bucket. (Allowing "default" for content-created buckets would seem to create potential web-compat issues, especially if it created a medium priority for data clearing on storage pressure, which would likely massively incentivize its use.)

[evanstade]

It seems that the spec doesn't enforce a default IDB transaction durability and gives a hand-wavey "matches the bucket's default" (where buckets are very much under-specced at the moment).

I'd be in favor of trying to push through a default of relaxed on Chromium --- the spec isn't standing in the way --- and spec'ing relaxed as the value for the default bucket. I say "value" rather than "default setting" because I'm also currently leaning towards making it impossible to change properties on the "default" bucket, and anyway durability is not something that can be changed after bucket creation (as per the current explainer, anyway).

@asutherland in your eyes is there a clear use case for being able to open and/or modify the "default" bucket explicitly? I guess it sidesteps the need for migration (of data from the current "default" bucket to a new explicit bucket), should authors want to apply an expiration to that data, say.

[asutherland]

Allowing an origin to be a good citizen and more tightly bound the origin's data usage lifetime seems like it could be nice, especially for sites that create throwaway origins for sandboxing purposes that are not likely to be revisited in the future like codepen. For example https://bugzilla.mozilla.org/show_bug.cgi?id=1778303#c7 is an example of a Firefox user who seemed to have data for hundreds or thousands of Google Colab origins. This could allow an origin to provide for prompt cleanup of LocalStorage data as well as storage API usage that didn't explicitly take the required steps to use explicit buckets, such as might be the case for codepen.

[evanstade]

Interesting point. Doesn't the UA already evict based on LRU when there's storage pressure though? If the UA is bogging down due to too much data, I would think that should count as "storage pressure" (if each origin is actually not using much storage, so there's no lack of disk space, then the UI probably could be made to more gracefully handle lots of origins). The UA can't really rely on sites volunteering to have their data evicted in order to provide a snappy user experience. IOW, it seems like that bug requires another solution besides just giving site X the tools to help make it happen less often, and hoping those tools are applied.

Expiration date, to my mind, is more of a hint about which subset of an origin's data should be evicted first, rather than which origin should have its data evicted first. There's an incentive to use it for the former reason (better experience on your own site), and disincentive to use it for the latter reason (worse experience on your site for the benefit of other sites). That is, bad/oblivious citizens would get preferred treatment --- relatively more persistent storage --- over good citizens. The UA should be no less eager to evict site Z's data just because it failed to set an expiration date.