Storage Buckets API

[ayuishii]

HIQaH! QaH! TAG!

I'm requesting a TAG review of Storage Buckets API.

The core of the proposal is granting sites the ability to create multiple storage buckets, where the user agent may choose to delete each bucket independently of other buckets. By contrast, today's user agents have a binary choice of either persisting or deleting all the data stored by a site.

• Explainer: https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md
• Security and Privacy self-review²: https://github.com/WICG/storage-buckets/blob/gh-pages/security-privacy-self-assessment.md
• GitHub repo: https://github.com/WICG/storage-buckets/
• Primary contacts:
  • Ayu Ishii (@ayuishii), Google Inc., specifier / implementer
  • Victor Costan (@pwnall), Google Inc., specifier / implementer
• Organization/project driving the design: Chromium
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5739224579964928

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/storage-buckets/issues
• Major unresolved issues with or opposition to this design: none
• This work is being funded by: Google Inc.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[kenchris]

Hi there,

Thanks for the great explainer, we are generally supportive of this idea, but would like to review the API a bit more in detail. We usually don't want IDL listings in the explainer, but as you don't have a spec at this point, would it be possible to add an API.md file with all the proposal API? Thanks

[ayuishii]

Hi @kenchris ! We added an API.md file that outlines the IDL to go with the proposal. Thanks!

[kenchris]

We (mostly @hober and me) looked at this in our TAG breakout, we have some naming concerns and other similar concerns... but overall it seems fine.

We are not a fan of APIs with openOrCreate - it could simply be called open or have a "create: true" as part of options, but we think auto creation is fine.

All storage buckets have a name and also a title (metadata) you can set. You can go into settings and see a descriptive name. You run into issues of a11y, i18n and generally user agents have been reluctant to expose author-provided strings in security UI like that.

Now a fan of the name of persist. It is unclear what it does and it is unclear if it modifies the object. Our naming advice would suggest a simpler name - like "save". Depends on what persist does.

Regarding durability concept - durability relax/strict - is the UA free to delete things things? But even in strict if the UA is under storage pressure it's gonna get rid of your stuff. So - don't like APIs that imply to the author that this is durable.

Maybe something like "ephemeral" and "important" would make more sense, as you indicate if you care about the content or not.

setExpires -- doesn't it make sense to call it setExpirationTime? setExpires sounds like a boolean.

[torgo]

It seems like this could be a win from a data minimization perspective - if it allows the developer to set an appropriate expiration over certain categories of data. This could aid user privacy.

[ayuishii]

Thanks for the feedback @kenchris, @hober & @torgo!

We are not a fan of APIs with openOrCreate - it could simply be called open or have a "create: true" as part of options, but we think auto creation is fine.

Sounds good, we can update this to open and auto create the Storage Bucket. (WICG/storage-buckets#26)

All storage buckets have a name and also a title (metadata) you can set. You can go into settings and see a descriptive name. You run into issues of a11y, i18n and generally user agents have been reluctant to expose author-provided strings in security UI like that.

Sounds good, thanks for pointing this out! (WICG/storage-buckets#27)

Now a fan of the name of persist. It is unclear what it does and it is unclear if it modifies the object. Our naming advice would suggest a simpler name - like "save". Depends on what persist does.

Sorry for the confusion here. Our intent (which I should probably more explicitly point this out in the explainer) was to adopt the StorageManager.persisted()/StorageManager.persist() feature and keep the naming consistent for user created Storage Buckets. StorageManager.persist() is a feature on the existing default bucket and the thought was to keep this feature for user created Storage Buckets as well.

Regarding durability concept - durability relax/strict - is the UA free to delete things things? But even in strict if the UA is under storage pressure it's gonna get rid of your stuff. So - don't like APIs that imply to the author that this is durable.

Sorry for the confusion here as well. This is specifically meant to be durability in the face of power failures and was named to be consistent with durability in IDBTransaction. But we realize this naming here isn't the most clear... would you have any suggestions for better naming for this option in terms of power failure?

setExpires -- doesn't it make sense to call it setExpirationTime? setExpires sounds like a boolean.

Would this just be for the setter, or would you expect the getter also be expirationTime() as well? We wanted to keep expires() consistent with Cookie Store API, therefore we thought setExpires would be a good matching setter. But I can see how it may sound like a boolean as well.

Thank you!

[kenchris]

The feedback sounds sensible, and we are happy to see this move forward

Have you thought about what venue you want this to end up in after WICG?

[cynthia]

Sorry, found it. https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md#stakeholder-feedback--opposition

[torgo]

Can you provide a little more info on the positive developer feedback on this that you mention in the multi-stakeholder feedback section? Also, referencing Ken's comment, it would be good to see some more evidence of multiple implementations such as a positive Mozilla standards position?

[ayuishii]

The feedback sounds sensible, and we are happy to see this move forward

Awesome, thank you!

Have you thought about what venue you want this to end up in after WICG?

We see this eventually being a part of the Storage Standard.

Can you provide a little more info on the positive developer feedback on this that you mention in the multi-stakeholder feedback section? Also, referencing Ken's comment, it would be good to see some more evidence of multiple implementations such as a positive Mozilla standards position?

We've had developer participation & positive feedback in our in our TPAC breakout sessions in 2019 [1] & 2020[2] including participants from the Washington Post who have expressed interest in being early testers. We also are working with an internal Google partner who is interested in this API.

As for implementor interest, we have done a joint TPAC 2019 presentation with Mozilla, with some more context on this thread (whatwg/storage#2). But I've just requested a formal position here which will hopefully reflect this. Although no formal position from Safari at this point, they have actively participated in our discussions in TPAC 2019 [1] & TPAC 2020 [2].

[1] TPAC 2019 discussion: doc
[2] TPAC 2020 discussion: minutes

Thank you!

[ylafon]

Hi,
Just a quick question, as partitioning might happen in storage as well, how does it impact Storage Bucket API?
Thanks

[ayuishii]

Hi @ylafon,
Storage Buckets API won't conflict with storage partitioning efforts. We are in communication with the team and making sure the implementation design allows for both.

As for Storage Buckets API support in storage partitioning, it is still undecided. It will likely follow the pattern of other storage APIs and will be partitioned in 3rd party contexts. However, there is consideration of not allowing for Storage Buckets API in partitioned storage as well.

[ylafon]

Thank you for the clarification.
To reiterate what @kenchris said: we are happy to see this move forward.