- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 30 Jul 2010 19:18:26 +0100
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.htm>
Received on Friday, 30 July 2010 11:18:26 UTC