[whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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.
>

Local storage is not a good API for more complex applications like gmail.
 That's why I suggested integrating into IndexedDB and WebSQLDatabase (which
is what I meant when I said "databases").  Note that I also suggested that
it could be an optional parameter to setItem which would make it a per-item
setting and still be backwards compatible with LocalStorage.  (Like I said,
creating another LocalStorage-like API just for this feature is really not
an option.)

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

Nikunj has already said no more major features for v1 of IndexedDB.  I think
we might be able to sneak in an expiration parameter, but encryption 1) is
not practical for v1 and  2) we're really jumping the gun on this encryption
thing.  One person proposed it.  We haven't seen any evidence this is a
widely sought after feature.  If _anything_ the right way to go is to make
encryption fast and allow developers and authors of libraries to layer the
two.  If there's compelling demand, THEN we should talk about adding it to
individual APIs.


> > 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.
>

As stated, a more general purpose crypto API should be enough to satisfy
this use case and others (like someone wanting to encrypt it client side
before sending it to the server).  That is the direction these discussions
should be headed, not taking one particular persistent storage API
and finding a way to tack encryption onto it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100408/05919303/attachment-0001.htm>