– DRAFT –
Storage Buckets API

rssagent, bookmark

prepare this meeting

rssagent, this meeting is about Storage Buckets

Discussion on Storage Buckets API Proposal https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md

starting soon, to let people join

in 1 more minute

starting now

Ayu Ishii presenting, Victor Costan helping as well

presentation: goals, use-cases, explainer overview, Q&Discussions

problem: 1 default bucket for storage. they lose all or none of their data during storage pressure

no tools to better manage their storage

could prioritize some data, e.g. songs and playlist

goal: give apps more control over how data is stored and evicted

with buckets, apps can partition by data, cache, etc

e.g. favorite songs, playlists to be evicted last

more use-cases: email clients can cache messages and attachments

drafts not stored yet on the server

with browser eviction, all data would be lost, including drafts not sent yet

with buckets, this data could be partitioned and preserved

policies: a bucket could be evicted on storage pressure

and some data to be evicted last

tradeoffs, data could survive power failures, at the cost of battery consumption

how buckets could be used: 1 bucket per account

on logout, data cleanup would be the deletion of the specific bucket

code example: how to create a bucket

options for durability and persistence

in example: strict durability to minimize data loss

title: for the UA to display the bucket title in the UI

example was unimportant bucket

for managing quota, proposing a quota option

expires option, to ensure data isn't accessible after a certain time

deleting buckets. delete API. could be used on user logout

service workers: each storage bucket could store SW registrations

<pwnall> Slides: https://docs.google.com/presentation/d/1q8wRn2Q3BddAErKd5Sq6vDx4w6W5UqCEd6PaBxqJ0Kg/

early state. with tag review. want to get feedback

floor open to questions / discussion

<annevk> JohnWilander: https://github.com/WICG/storage-buckets/blob/gh-pages/explainer.md#storage-policy-expiration

<JohnWilander> https://github.com/privacycg/storage-partitioning

for cookies, no plans on supporting cookies in buckets

<asuth> The Storage spec has a concept of sheds and shelves which would relate to the partitioning: https://storage.spec.whatwg.org/#storage-shelves

<asuth> Buckets explicitly already operate at a granularity beneath those.

expiry: guarantee is that data is inaccessible after expiration

it won't be retrievable when storage pressure occurs

does proposal introduce expiry for storage?

part of the option, but not a required option

if you don't state an expiry, it's in memory only?

should've been there from the start

on cookies: when starting buckets, tackled quota managed storage

cookies: synchronous API, etc. each browser has a small fixed amount of quota

does everything hang off of buckets? yes

will it happen in the next few years? unlikely

with proposal, starting with small steps

fix problems, and iterate

cookies are special... wondering if allowing sites to somehow tell the browser to delete cookies, and keeping some, e.g. login cookies

partitioning: partitioned+ storage buckets?

talking to folks in Google who are more familiar. following options, not ready for scrutiny

looking at 1P contexts first, 3P later

probably more specs/explainers in addition later to this proposal

shelves and buckets are already explicit. partitioning is already answered by the spec

depends on how CG interacts

this explainer does not change any of how that works

unaware of this until this week. no time to consume in full, but appreciate the problems this is trying to solve

eviction of a whole origin? carefully designed, but hand-wavy and not good data on this

no aspect seems great

earlier this year webkit made changes to eviction policy. due to privacy, good explanation

but people reacted based on misunderstanding on how it works in other browsers

opened an issue on chrome

use low-end device for 5 years

things get evicted all the time

no discussion about that and what that means to your ability to have cache

know of efforts to collect data on how often eviction happens?

<pwnall> Our latest attempt at documenting some of this behavior: https://web.dev/storage-for-the-web/

we do collect eviction data

(we): Chrome

could make it more clear around evictions to incentivize sites to use storage

good suggestion. hard to define what the rules would be

could eviction data be published?

based on UA? what's the policy around this?

related to explainer: let developers give more preferences on how data should be evicted

until recently, how eviction works was not a well understood process

we now have a better understanding of all the cases

we have published an article that explains what we do and what other browsers do

https://web.dev/storage-for-the-web/

we have metrics and we'll see what we can release

(we): Chrome

goals focusing on prioritization, could segment by users

offering new features around storage... expiry

some users have to use it forregulatory reasons

aram: Eng Director at WaPo

incentive to evict data less?

privacy focused browsers come to mind

what's the incentive to the UA not to evict to be more private?

(or to evict?)

what incentive can i give to a browser to not evict some data because it isn't privacy sensitive?

still figuring out what it means RE: 3P storage

complicated space, lots of options, nothing useful to say at this point

asuth: won't impact privacy behavior at all

clearing origin clears everything about this origin

exiting the session? it's all going to get cleared

this is just giving options surrounding eviction options

LRU? evicted

movie-watching site a kid watches every day, will let browser evict data that's already used

i.e. FMV data

exposing more granular things to user: delete some data, and not other stuff... delete data but not UI

storage gets cleared for a few reasons: 1) user clearing browsing data, proposal has no effect on that

will clear all buckets

could be more options there? not yet

2) under storage pressure, disk is getting full

this proposal applies

opted in by the site

default behavior is that under pressure, all data is wiped

if a user is clearing data for privacy reasons, all data will be cleared

question: do you consider automatic expiration? how session storage automatically expires

or session cookies removed when browser is closed?

not currently in the explainer

it could be something we create an issue for

and consider use-cases

could add to the explainer after elaboration, perhaps

muodov: will elaborate

<asuth> There is a storage spec issue on sesssion buckets already: https://github.com/whatwg/storage/issues/71

could be copied over in popups?

does the use-case rely on that?

popups: window.open, target=blank, etc

dynamically created subdomains, using sessionstorage to have some state

goes away when you close the tab

survives tab reload

would be very nice if it is possible to separate/partition storage

bkardell jumps the queue: company was adamant that it was necessary to reflect your 'session' in any tabs you were in, and they did open new windows. But also that was a nightmare. For whatever that is worth which tab a user is in. inability to sync data is a nightmare

<annevk> bkardell___: so it's quite specific, if the user opens two tabs independently they wouldn't share sessionStorage

<annevk> bkardell___: and you'd have to use BroadcastChannel or some such

referring to functionality in Safari: deleting website data for domains

<annevk> bkardell___: sessionStorage is only copied over from a starting tab to a new one opened from there

not because there's a lack of storage or user going through storage settings

part of privacy protection

maybe there's a way for buckets to inform this feature

data important for functionality, take that in consideration before clearing data

chrome lacks same-site cookies by default

same-site none: cookies i intend to use in a partitioned context

more likely to go away?

feature: clear all cookies that could be used in a 3P context

not an outlandish thought

could ever get to a good faith situation there?

where functionality in buckets wouldn't be misused to store tracking data

JohnWilander mentioning to muodev: sessionstorage similar, per-tab, per-session

sessionstorage is weird in other ways

ties to the tab not to the origin

should be revisited

muodev: that's what's missing

storage buckets is an opportunity to fix several of the problematic things in earlier storage specs

aram: yes, exactly what was in mind

would not rely on the occurrence of this API right now

but hopeful

data not accessible to 3P, so don't clear

etc

data is protected, that makes it not accessible to 3P in a more dynamic way, so don't clear it

looking for ways to make it easier to retain a login for users

while respecting the choice of UA RE: privacy

and dynamic clearing for that reason

might not be the proposal

but might be a future proposal?

durability?

sessionstorage, storage gets cleared, association with tab and cleared on shutdown

should there be a bucket that gets cleared on browser shutdown?

muodov: ideally, replicate sessionstorage, tied to tab

question more general: cookie. clearing when browser is shutdown? strange

question is more like: would we consider any type of automatic removal that's not defined by an expiration date

HTTP-only cookies?

protocol things, not JS

can't get to HTTP-only cookies

things goes towards what you want

want ability as a dev to say: this is my indexeddb. even if i run 3P code, they shouldn't get access to this

please consider this more isolated and not tainted... keep it around

aram: very interesting dimension

bucket we wish to be very isolated from any 3P

in exchange for that, store it longer?

could be passed by network request...

1P leaking deliberately to 3P, different use-case

could achieve the same by opening an iframe and never load 3P data there

"is logged in" very interesting idea

talking about a 3rd state

data stored and available to site, data evicted for whatever reason

in the middle, "is logged in", hiding data

some time has passed. UA hides data, keeps it around

e.g. email drafts

could find middle ground with "forever storage"

tied to user being logged in

WaPo could be early devs/testers

lots of work right now, but after that

interested

<bkardell___> this is very interesting, thank you for this session

please file github issues

to continue discussion

want more clarity and use-cases

this is the 1st version of this API

will iterate

storage specs has endpoints

would imply that this requires File System Access

next-steps? one small point of confusion

scoping-wise: chrome indicated they were thinking of re-doing quota management

not dependent on free disk-space

if quota bucket storage is intended to be part of that change, or informative?

document how eviction works with quota management?

answer: yes. would love help to write the spec to get it right

chrome around quota: don't consider free disk space anymore when computing quota

because of security issues discussed in the explainer

hoping buckets gives sites a way to explain how storage is structure

future: allocating and logging quota

firefox has some thoughts

should consider opinions together

doing some work there, good direction, shouldn't be a big feature bloat on the spec

explainer -> diffs on storage specs, do small steps

zero: on internal Google team

chrome and firefox: different models to grant permissions

popups vs implicit grant

will allow users to define and persist permissions in different buckets?

existing mechanisms from UAs? challenging for popup mechanism to deliver in this new world

want to hear from both Chrome and Firefox

any idea of unifying the grant process?

asuth: storage spec specifies a permission to get the ability to persist things

request persistence or not

browsers don't want to standardize UX on how that works

Firefox: an explicit prompt, no plans to change that

it's always difficult to provide informed consent to users when they're not under duress

chrome uses frecency

buckets allows firefox to provide more data to provide stronger things there

firefox as a UA: goal not to provide a contract to a site to never delete

it will be UA-biased. UI won't be standardized

in Chrome: no popups because there's no good way for users to make an informed decision

aligned on general idea

want buckets API to allow UA to make a per-bucket decision

in a future world, if you have a small bucket, persistence could be granted without any trouble

<MikeSmith> https://wicg.github.io/storage-buckets/explainer#introduction “This explainer proposes changes to the Storage Standard.

writing messaging client with encryption, keys could be stored in a bucket, and messages in another bucket that could be evicted

similar to Firefox: persistence does not override users' will

might show warning: hey developer, you thought this was important before, etc

but won't block on deleting

<Zakim> MikeSmith, you wanted to ask about where this spec will live

MikeSmith from w3c in tokyo

plan for spec to live wholly within storage standard? or to have something else in addition to that?

would be in storage spec

to have buckets entirely

<AramZS> yes, thank you!

asuth: thanks for working on this

please create issues and keep discussing

<pwnall> everyone: Please let's continue the discussion on GitHub issues!