[whatwg] Proposal for Web Storage expiration

[Jeremy Orlow]

On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut <Alexandre.Morgaut at 4d.com
> wrote:

>
> 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
> menus/preferences.
>
> 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
worse.

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?)

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100730/dabfdc07/attachment-0002.htm>