- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 7 Apr 2010 18:10:16 -0700
On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow <jorlow at chromium.org> wrote: >> I don't think this is enough of a >> problem to kill the feature though. > > I think this is a good feature to try and integrate into existing APIs if > it's possible to do so cleanly. ?I don't think it's worth creating yet > another?persistent?storage API over, though. ... > For > localStorage, we could add a origin-wide setting or add an optional param to > setItem. Well, it seems harsh to require that *all* data on a domain is either security sensitive, and thus need expiration, or not security sensitive and thus need none. I think it makes a lot of sense to be able to let the page have several storage areas, some which expire and some which don't. Think mail.google.com where storing my emails would count as sensitive and should have expiration, but storing my drafts might be worth doing longer to prevent dataloss. I just thought of an alternative approach to this whole situation though. We could add crypto and expiration functionality to IndexDB. I know the crypto stuff has come up before and there was some hesitation though. (Though I guess the same thing could be said for crypto+localStorage) > It seems as though expiration policies could be added to the creation of > databases and the new FileWriter/FileSystem APIs pretty easily. I don't understand the usecase of expiring files. Isn't the whole point of saving to the file system so that the user gets better access to it and so that things like iPhoto can index any stored images? > But still....we need some use cases. ?:-) I'm all for use cases. Though Nicholas did say that he'd want encryption and expiration on essentially all privacy sensitive information stored. Which I think I can understand. / Jonas
Received on Wednesday, 7 April 2010 18:10:16 UTC