I'm also not keen on UA sniffing for the determination of features, which is why I mentioned using localStorage.setItem.length to determine if the TTL parameter is valid for the browser.
IMO, it's fine not to delete the data while the page is loaded, but I would like to ensure that the data isn't able to be read if the expiration time is reached during the page lifecycle. 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. -Nicholas ______________________________________________ Commander Lock: "Dammit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." ________________________________ From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow Sent: Friday, July 30, 2010 11:18 AM To: Alexandre Morgaut Cc: whatwg@lists.whatwg.org; Nicholas Zakas; Jonas Sicking Subject: Re: [whatwg] Proposal for Web Storage expiration On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut <alexandre.morg...@4d.com<mailto:alexandre.morg...@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
