[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] Proposal for secure key-value data stores
From:       "Nicholas Zakas" <nzakas () yahoo-inc ! com>
Date:       2010-03-31 0:13:02
Message-ID: 4E45EC6AD219FD47AD1BC06E4EE3845D04A42C80 () SNV-EXVS09 ! ds ! corp ! yahoo ! com
[Download RAW message or body]

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is \
eliminate what I believe will be a repeated pattern for developers in the future. It \
would be really nice if, in addition to having access to crypto functions, there was \
an area where I could stick data that would get encrypted automatically (and of \
course, where I could be sure the data would be eliminated after a set amount of \
time).

My proposal is less about encryption and more about providing better control over how \
data is stored and for how long.

-Nicholas
 
______________________________________________
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On \
                Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas <nzakas@yahoo-inc.com> wrote:
> Yes, that's precisely what I'm talking about. It seems to me that this will end up \
> being a pretty common pattern (encrypting/decrypting data stored locally). 
> The idea behind letting the key to be defined by the developer is to allow any \
> usage that developers deem appropriate for the situation. For example, one might \
> want to only use a server-generated key to access the data, in which case this data \
> won't be available offline but will be used to supplement the online behavior. \
> Another might determine the key based on some information in a cookie, which is \
> less secure but does allow offline access while also ensuring that if the cookie \
> changes or is deleted, the data remains secure. 
> The idea behind the expiration date is to allow developers to be sure the data \
> won't stay around on disk indefinitely. Think about the Internet café use case \
> where people are repeatedly logging in and out - we don't want everyone's data \
> living on that computer for however many years it's in use. 
> One way or another, I think JavaScript crypto is going to be important in the next \
> few years.

Perhaps we should instead focus on a set of JS Crypto APIs, since that
is largely orthogonal to the storage APIs?

-- Dirk


[prev in list] [next in list] [prev in thread] [next in thread]