[whatwg] Proposal for Web Storage expiration

[Scott Hess]

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