<div class="gmail_quote">This is getting fairly tiresome. If you're interested in continuing this thread, please actually read the replies thus far and directly respond to the points rather than re-stating what's already been rebutted.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan <span dir="ltr"><<a href="mailto:paulkinlan@google.com">paulkinlan@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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></div></blockquote><div>These are not use cases. Can you please describe some specific examples applications and their requirements for encrypted data? To be honest, I'm pretty certain you're not going to come up with any that aren't solved by what you can do today with JS, made better with a JS crypto API, and made easier on the developer by integrating crypto into the storage APIs. (Though as I explain below, the last part is pretty much a non-goal.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><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.</div></div></div></blockquote><div><br></div><div>
Then someone should make a library to do this. Expanding the surface areas of APIs should not be taken lightly. As I've explained, we only expand API surface areas when something is impossible to accomplish or when there are performance reasons. And then we still try to keep things minimal. Dirk explained well why a generic JS crypto library would solve more use cases than adding crypto to a particular storage API. I really don't know why we're still discussing this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div>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></div></blockquote><div><br></div><div>What's been proposed so far will NOT work as seamlessly as HTTPS.</div><div><br></div><div>If you want it to happen magically, then the UA should encrypt all data transparently to the user or web developer. I actually think this is ideal, but the problem is that it's not clear where the key should come from. After all, if you store it on disk, then you're still at the mercy of the file system/OS keeping you secure. If you store it remotely (as has been mentioned in this thread) then we need to come up with an API to pass that key in or we need to somehow add the key to HTTPS connections.</div>
<div><br></div><div>Maybe what we should really be doing is looking at adding a HTML attribute, HTTP header, or something like that that gives the browser a private key to be used to encrypt _everything_ associated with the web page. Including history, any storage APIs, etc. I suppose the file API would need some way to opt-out (per what Jonas pointed out).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div>In summary, this is something I expect of the UA and not any specific JS API.</div></div>
</div></blockquote><div><br></div><div>Although ease of use of JS APIs is great and should be a goal, it is not the primary goal by any stretch of the imagination. Keeping API surface area down is much more important.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div><div class="h5"><div><div class="gmail_quote">On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">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>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>
<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>
<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></div></div>
</blockquote></div><br>