On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas <nza...@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
