W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2010

[whatwg] Proposal for secure key-value data stores

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 7 Apr 2010 18:10:16 -0700
Message-ID: <j2k63df84f1004071810p26dd5bbcicd0784952a9d6e09@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:22 UTC