Skip ⬇

Storage Buckets API

Facilitator: Ayu Ishii

Speakers: Victor Costan

Slides

Minutes (including discussions that were not audio-recorded)

Previous: Web Install API - TPAC 2020 breakout sessio All breakouts Next: Virtual Keyboard Control

Skip ⬇

Skip ⬇

Transcript

At Google on the Chrome storage team, currently working on Storage Buckets API explainer with Victor who'll be helping me out today as well.

And my pronouns are she and her, and I guess I'll get started.

So just a quick agenda.

I'd like to go over the goals, use cases, and current explainer overview.

In about five to 10 minutes, and then hopefully leave the rest of the time for questions and discussions to the end.

And okay I guess I'll just jump right into it.

So the problem now we're trying to solve is Storage Buckets API is that currently websites have one default bucket for storage, and they either lose all or none of their data during storage pressure.

And they have no way to express performance or durability trade-offs on browser eviction, and there's no tools or incentives for developers to better manage their storage.

So for example, if c.com or a music player, they might store your favorite songs and custom playlists, as well as content like latest hits or recommended music.

But on storage pressure, instead of being able to prioritize your favorite songs, and custom playlists, all your stored music will be evicted.

So for the goal of storage buckets API, so is to give applications more control over how their data is stored and evicted.

With buckets, websites can partition their storage, whether it's by feature or count, et cetera, and specify different storage policies and set prioritization.

So for the music player example, the website can prioritize favorite songs, and customize playlist to be evicted last.

For some more use cases, email clients now might store cashed inbox messages, and attachments from server, as well as email drafts that have been worked on offline, and haven't sync to the server yet.

And this will be all part of the default bucket.

And the problem with this is that on browser eviction, there's a possibility that all this data will be erased.

Including the email draft that will be lost forever.

And so with buckets, email clients can partition data, and assign different storage policies to prevent this.

For example, there can be a bucket just for cashed inbox messages and attachments, with a policy that says it can be evicted on storage pressure.

And on power failure, it's acceptable to lose the last few rights.

And then another bucket for drafts, which specifies a policy that tells the user agent to evict the bucket last.

All data should survive power failures at the cost of more battery consumption.

So on browser eviction in this case the inbox bucket would be the first to be evicted, and which hopefully would create enough storage availability.

Another example of how buckets can be used is websites can choose to create a bucket per account.

Here we show an account picker with multiple logged in accounts for enterprise and personal accounts.

And on log out, data cleanup would just be simply deleting a bucket for the account.

So moving on to the proposed interface here to create important buckets.

For example, the drafts bucket for the email client.

We're gonna create with the first parameter as the name of the bucket, followed by bucket options for durability and persistence.

Here we have durability strict to minimize data loss at the cost of better consumption, and then persisted true to request persistent storage.

Title for, if the user agent wants to display the title for the quota manager UI.

And once a bucket is created, it will have entry points to cash storage, index DB file API, and file system access API.

To create an unimportant bucket, similar to the previous slide, except for, here we have durability relaxed.

To deprioritize and power loss, and persisted false to tell user agents to evict first under storage pressure.

For managing quota, we propose a quota option to specify quota for a bucket.

This can ensure that one bucket or feature won't eat up the entire origins quota.

We also propose expires option to ensure that data is inaccessible after a certain date or time.

This can be used for buckets that aren't relevant anymore after a certain time, or if there's a requirement that data should be inaccessible after a certain date.

Deleting buckets, it can be deleted with the delete, and the name of the bucket.

It can be used on a user log out.

Servers Workers and Clear-Site-Data.

So here we propose each storage bucket can store service worker registrations.

This can be used to register a service workers to the same bucket as the stored data it's expected to access.

And when eviction occurs and the data is inaccessible, the service worker will be cleaned up as well.

Here we also propose to support deletion via Clear-Site-Data.

So that's a very quick overview of what's in the current explainer.

Currently, we're gonna we're starting to prototype in chromium.

We kicked off an early tag review, and hoping to get some feedback today.

And identifying developers interested in early testing.

So with that, that's kind of the end of the presentation portion.

I'd like to open it up to questions and discussion.