Sorry for misunderstanding your original suggestion.<br><br><div class="gmail_quote">On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas <span dir="ltr"><<a href="mailto:nzakas@yahoo-inc.com">nzakas@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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).<br>
</blockquote><div><br></div><div>It seems to me that Dirk is right that crypto in the browser is a more general problem and that a general crypto API would be much more valuable than creating new APIs with similar/duplicate functionality + crypto. Optimizing for "repeated patterns" probably should wait until we see what patterns are actually common. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My proposal is less about encryption and more about providing better control over how data is stored and for how long.<br></blockquote><div><br></div><div>Can you provide some concrete use cases for expiration of content? They'd probably have to be pretty dramatic to warrant creating yet another storage mechanism.</div>
<div><br></div><div>Maybe this can somehow be integrated into IndexedDB? There's very little chance of it being a v1 feature, but maybe we could make sure it's possible to add in future versions.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
-Nicholas<br>
<br>
______________________________________________<br>
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"<br>
Morpheus: "My beliefs do not require them to."<br>
<br>
-----Original Message-----<br>
</div><div class="im">From: <a href="mailto:whatwg-bounces@lists.whatwg.org">whatwg-bounces@lists.whatwg.org</a> [mailto:<a href="mailto:whatwg-bounces@lists.whatwg.org">whatwg-bounces@lists.whatwg.org</a>] On Behalf Of Dirk Pranke<br>
Sent: Tuesday, March 30, 2010 3:09 PM<br>
To: Nicholas Zakas<br>
Cc: <a href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a>; Jeremy Orlow<br>
Subject: Re: [whatwg] Proposal for secure key-value data stores<br>
<br>
</div><div><div></div><div class="h5">On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas <<a href="mailto:nzakas@yahoo-inc.com">nzakas@yahoo-inc.com</a>> wrote:<br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> One way or another, I think JavaScript crypto is going to be important in the next few years.<br>
<br>
Perhaps we should instead focus on a set of JS Crypto APIs, since that<br>
is largely orthogonal to the storage APIs?<br>
<br>
-- Dirk<br>
</div></div></blockquote></div><br>