[whatwg] Proposal for Web Storage expiration
Simetrical+w3c at gmail.com
Wed Aug 25 15:25:00 PDT 2010
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).
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.
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
Those are off the top of my head. I don't know if they're compelling
enough to add the feature, compared to all the other features that
might be desired, but it certainly seems fairly useful.
More information about the whatwg