[whatwg] Proposal for Web Storage expiration

[Ian Hickson]

On Thu, 29 Jul 2010, Nicholas Zakas wrote:
> 
> The Web Storage specification provides two ways for web applications to 
> store key-value data in the browser, effectively replacing cookies for 
> cases when the server doesn't need the information. For a lot of web 
> application needs, sessionStorage and localStorage (or some combination 
> of the two) can be used to effectively reduce the number of cookies 
> used. Cookies do have one advantage over these APIs: the ability to 
> specify an expiration period after which the data is removed.
> 
> Right now, if a web application developers wish to have expiration of 
> key-value pairs, he/she must manually implement such expiration on their 
> own. An example of an API that already does this is XAuth (xauth.org).
> 
> Proposal: Adding the ability to optionally define an expiration date for 
> each key-value pair would bring sessionStorage/localStorage closer the 
> capabilities of cookies today and provide useful control over the length 
> of time that certain data can live in the browser. This becomes 
> especially important if any authentication-related data is to be stored 
> in Web Storage.

I'm reluctant to add new features right now to this API, since there's so 
much other stuff for browser vendors to implement and bug fix, but 
expiring data is something that's been on the list of "v2" features for 
Web Storage for some time, so I'm sure we'll add it eventually.


On Thu, 5 Aug 2010, Jeremy Orlow wrote:
>
> As far as I can see, the next steps are (roughly in order):
>
> 1) Figure out whether it should be an origin wide setting or not.  In 
> order to prove that it needs to be a per LocalStorage bucket setting, 
> its on you to come up with use cases where an origin wide setting is not 
> enough.  By use cases, we mean specific examples of stuff that clearly 
> happens in reality today or would happen in reality if this was added.
>
> 2) Come up with a concrete proposal for what be added to the spec.
>
> 3) Find a UA willing to prototype such a new feature.

That is indeed a good route to follow.

It would also be good to document the reasons why people want to expire 
data. It's presumably not security -- you'd want to expire the authority 
of any credentials on the server side long before it became an issue to 
have them stored on the client side. It's presumably also not just wanting 
to clean things up -- browsers are going to have to deal with expiring old 
storage data that the user hasn't used anyway, whether we let the site 
clean up after themselves or not.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'