search

WICG / shared-storage

Explainer for proposed web platform Shared Storage API
Other
85 stars 18 forks source link

Removing max key count, max key length, and max value length in favor of max db size #99

Open jkarlin opened 1 year ago

jkarlin commented 1 year ago

Since shared storage is cross-site data, just knowing the size of your origin's shared storage database could leak significant information. Therefore, Shared Storage is not quota managed, and the size of the origin's database is not web exposed.

Because it's not quota managed, we've put a cap on the size of each origin's shared storage database. But we enforced that cap by limiting the key and value lengths, and the number of possible keys. In retrospect that seems overly constraining to me, when we could instead just have a single size limit for the origin that we enforce, allowing developers to use that space as they see fit.

Any thoughts or comments on making such a change? I don't have anyone asking for this change right now so it's not high priority, but would be interested to hear from folks.

SpaceGnome commented 12 months ago

Seems reasonable to switch to an overall single size limit, but agree doesn't seem high priority given the existing key/value pair limits and their lengths.

pythagoraskitty commented 6 months ago

We are proposing to move ahead with changing the storage quota model as described above.

Previously we allowed a total number of key-value pairs per origin, with keys and values having a maximum character limit of 1024 apiece.

We propose to move instead to a model where each origin would get a total of 5MB of shared storage that they could allocate across key-value pairs according to their needs.

Our goal in doing this is to increase utility/ergonomics for developers, so we welcome feedback about this proposal. Any thoughts or comments?

jdfreder commented 6 months ago

I don't foresee this change causing any problems with unique reach measurement.