W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Proposal for Web Storage expiration

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 25 Aug 2010 22:33:53 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1008252231500.27869@ps20323.dreamhostps.com>
On Wed, 25 Aug 2010, Aryeh Gregor wrote:
> On Tue, Aug 24, 2010 at 7:13 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 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.
> 
> 1) Even though browsers might have to do forcible cleanup once in a
> while, if sites can ask for certain things to be expired, this will
> reduce the frequency with which browsers need to delete sites' data
> without permission (ideally to zero in most cases).

This relies on sites actually using this feature. I don't see any reason 
to believe sites would use this enough to make a dent here.


> 2) If a site allocates small amounts of data on a regular basis for
> various types of caching, and it doesn't expire, it will accumulate
> over time and eventually hit the site's quota.  This will be hard to
> predict and won't show up in testing, since it might only happen after
> months or years of regular use.  Providing a built-in expiration
> mechanism will help authors to avoid this mistake.

If an author is aware enough to do this, then he's presumably also aware 
enough to just crawl through the existing keys, nuking the ones that are 
no longer in use.


> 3) If client-side data becomes obsolete in a predictable timeframe,
> like server-side expiration of the corresponding credentials, then it
> shouldn't be used after that date (since it's known that the use will
> fail).  Client-side expiration is a convenient way to model this
> situation.

That can easily be done without UA support.


I'm not saying there are no use cases here, but the ones listed above 
aren't very compelling in practice, I think. It would be good to know what 
use cases exist that don't have simple workarounds or alternatives.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 25 August 2010 15:33:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC