[whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present.

Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. 

I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way.

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: Scott Hess [mailto:shess at google.com] 
Sent: Friday, July 30, 2010 5:05 PM
To: Nicholas Zakas
Cc: Jeremy Orlow; Alexandre Morgaut; whatwg at lists.whatwg.org; Jonas Sicking
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> And I totally agree, this is not a strong security feature, and that's not
> the intent. The intent is just to give an extra measure of control of the
> lifetime of the data to bring Web Storage closer to being a replacement for
> a wider range of functionality that currently uses cookies.

I don't think this really follows.  Cookies were invented quite awhile
ago, and may not be a good model for development.  A reasonably small
dataset allows the client to expire cookies aggressively.  With large
local storage, doing per-item expiration is not a good idea - you do
not want your UA groveling through a gig of data you are not otherwise
using to expire a couple dozen items.  Per-database expiration might
make sense, because the expiration information could be stored in a
central location as a hint to the UA (if the site isn't going to use
the data after two weeks, might as well delete it).  Sites could
segment their expiration needs by using multiple data stores.

That said, idle storage is eventually going to be reclaimed anyhow, so
you could just ignore the problem.  Current storage proposals are much
richer than cookies, so the developer could just store dates alongside
their other data and make the decisions directly, no need for the
system to help.  Since the JavaScript accessing the data is executing
right next to the data, you don't have the latency issues
client/server communication introduces.  So long as expiration is a
SHOULD, its not clear to me that this idiom is powerful enough to
deserve footprint in the spec.

-scott