[whatwg] Proposal for secure key-value data stores

I tried to articulate some of my thoughts as to why a generate purpose
crypto isn't enough to be useful and why trying to tack onto local
storage could get messy:

http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side
-data-storage/

 

 

-Nicholas

 

______________________________________________

Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."

________________________________

From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 3:14 AM
To: Jonas Sicking
Cc: whatwg at lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

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/20100414/b9061538/attachment-0001.htm>

Received on Wednesday, 14 April 2010 17:23:22 UTC