[whatwg] Proposal for secure key-value data stores

[Jeremy Orlow]

Yes, |localStorage.setItem(AES.encrypt("username", key),
AES.encrypt("Nicholas", key));| is a bit ugly, but many things in the web
platform are.  And honestly, it's not _that_ ugly or _that_ many extra
characters.  And this is the type of problem JS libraries often solve.

I'd suggest you talk to various libraries (or write your own) about adding
a compatibility layer that includes JS crypto and in parallel talk to
browser vendors about adding a crypto API.

Anyhow, I can say with a fairly high level of certainty that we (Chromium)
are not interested in implementing this.  But maybe others (Mozilla?) are.
 So I'm going to withdraw myself from this discussion since I don't seem to
be adding any new information to it and I think everyone knows where I
stand.  :-)

J

On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas <nzakas at yahoo-inc.com>wrote:

>  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 at 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/6e5acff8/attachment-0002.htm>