Meeting minutes
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://
early state. with tag review. want to get feedback
floor open to questions / discussion
<annevk> JohnWilander: https://
<JohnWilander> https://
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://
<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://
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://
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://
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://
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!