Hi,<div><br></div><div>I have a specific use-case where encryption is required, and currently the only solution is to find a JS library that can encrypt the data on the way in or way out of storage.<div><br></div><div>The main cases I have:</div>
<div><ol><li>Storage needs to be encrypted on disk, device etc.</li><li>Data needs to be in�decrypted�form for the shortest amount of time possible while in use in an application.</li></ol><div>My gut, general feeling is that encryption of information to and from storage is moot, because introspection of a running app is so�unbelievably�easy. �However, on disk storage *must* be encrypted and sandboxed. �i.e, data needs to be only available to the domain running the code, and it cannot be peaked at by examining the disk.</div>
<div><br></div><div>I have only followed this thread a little while, and as dev who uses JS a lot, explicitly having to encrypt data is bad and a pain and open to mistakes. �I don't want to be handling encryption of my data, I don't do anything special to communicate over https, and I look at storage the same way.</div>
<div><br></div><div>In summary, this is something I expect of the UA and not any specific JS API.</div><div><br></div><div>P</div><div><br><div class="gmail_quote">On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>> wrote:<br>
>> I don't think this is enough of a<br>
>> problem to kill the feature though.<br>
><br>
> I think this is a good feature to try and integrate into existing APIs if<br>
> it's possible to do so cleanly. �I don't think it's worth creating yet<br>
> another�persistent�storage API over, though.<br>
</div>...<br>
<div>> For<br>
> localStorage, we could add a origin-wide setting or add an optional param to<br>
> setItem.<br>
<br>
</div>Well, it seems harsh to require that *all* data on a domain is either<br>
security sensitive, and thus need expiration, or not security<br>
sensitive and thus need none. I think it makes a lot of sense to be<br>
able to let the page have several storage areas, some which expire and<br>
some which don't.<br>
<br>
Think <a href="http://mail.google.com" target="_blank">mail.google.com</a> where storing my emails would count as sensitive<br>
and should have expiration, but storing my drafts might be worth doing<br>
longer to prevent dataloss.<br></blockquote><div><br></div></div><div>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.)</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just thought of an alternative approach to this whole situation<br>
though. We could add crypto and expiration functionality to IndexDB. I<br>
know the crypto stuff has come up before and there was some hesitation<br>
though. (Though I guess the same thing could be said for<br>
crypto+localStorage)<br></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> It seems as though expiration policies could be added to the creation of<br>
> databases and the new FileWriter/FileSystem APIs pretty easily.<br>
<br>
</div>I don't understand the usecase of expiring files. Isn't the whole<br>
point of saving to the file system so that the user gets better access<br>
to it and so that things like iPhoto can index any stored images?<br>
<div><br>
> But still....we need some use cases. �:-)<br>
<br>
</div>I'm all for use cases. Though Nicholas did say that he'd want<br>
encryption and expiration on essentially all privacy sensitive<br>
information stored. Which I think I can understand.<br></blockquote><div><br></div></div><div>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.</div>
</div>
</blockquote></div><br></div></div></div>