[whatwg] Proposal for Web Storage expiration
jorlow at chromium.org
Fri Jul 30 11:18:26 PDT 2010
On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut <Alexandre.Morgaut at 4d.com
> Storage::setExpiration(in DOMString key, in TTL or expiration Date)
>> (or Storage::setTTL() if you guys don't agree on the Date option)
> This might make sense, but I'm also not sure it's worth the additional API
> surface area. Plus I kind of like the idea of making it difficult for
> people to detect whether the browser even supports expiration since we don't
> people to ever assume they can count on it. (Since once again, what if the
> user doesn't turn on their computer or the UA doesn't delete expired data
> unless it's running?)
> Well, as Nicholas said, the important thing is that the User-Agent makes
> its best to remove the items ASAP once they expired.
> Sure some of these items could remain on disk while they expired until the
> UA start again.
> This is absolutely not a strong security feature.
> The user still should be able to remove manually the storages content, or
> disable access to the storage objects, from the User-Agent
> I'm not confortable into hiding User-Agent capabilities from the API.
> Smart people like John Resig recommend to check the available API instead
> of looking after the User-Agent name and version to detect them, and I kind
> of like this approach.
My point was that a programmer really shouldn't do anything differently
whether or not the API is available. But you're probably right that it'd
only push such an author towards user-agent sniffing which is of course
I just had another thought. Although I strongly feel that the spec
shouldn't guarantee when the data is deleted (and should probably have some
non-normative text explaining why) we could (if we wanted to) guarantee that
data won't be available to the page after that time. (Of course subject to
run to completion constraints--if the user calls localStorage.length, we
can't delete the item until they leave the scripting context. Also there's
a question of whether we'd fire StorageEvents while something's timed out.
Maybe we should just expire stuff when navigating to a page and not while
the page is running?)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg