[whatwg] Proposal for secure key-value data stores

I believe what I'm proposing is an incremental change to the
already-existing data storage API and not and doesn't drastically
increase the API surface area. Where the encryption key comes from I
think is an interesting question, which is why I didn't address that. I
think there will be (can be) a variety of places from where a key can
originate. I don't think it's necessarily important that a key
originated from a server be passed securely to the client. A lot of web
applications pass tokens back to the client for security purposes right
now. As long as there is a relationship between the signed-in user and
the key, you're generally covered.   

 

In any event, I think everyone has agreed that a JS crypto API would be
a good thing, yet no one has stepped forth with a proposal to move the
discussion forward. So here:

 

[Supplemental, NoInterfaceObject]
interface WindowCrypto {
    const unsigned short AES_128 = 1;
    const unsigned short AES_192 = 2;
    const unsigned short AES_256 = 3;
 
    DOMString encrypt(in DOMString valueToEncrypt, in unsigned short
cipher, in DOMString key);
    DOMString decrypt(in DOMString valueToDecrypt, in unsigned short
cipher, in DOMString key);
}
Windows implements WindowCrypto

 

Thoughts?

 

-Nicholas

 

______________________________________________

Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."

________________________________

From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 7:49 AM
To: Paul Kinlan
Cc: whatwg at lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Jonas Sicking;
Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

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.

 

 

On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan <paulkinlan at google.com>
wrote:

Hi,

 

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.

 

The main cases I have:

1.	Storage needs to be encrypted on disk, device etc.
2.	Data needs to be in decrypted form for the shortest amount of
time possible while in use in an application.

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.)

 

	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.

	 

	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.

 

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.

 

	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.

 

What's been proposed so far will NOT work as seamlessly as HTTPS.

 

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.

 

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).

 

	In summary, this is something I expect of the UA and not any
specific JS API.

 

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.

 

 

	On Thu, Apr 8, 2010 at 11:13 AM, Jeremy Orlow
<jorlow at chromium.org> wrote:

	On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking <jonas at sicking.cc>
wrote:

	On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow
<jorlow at chromium.org> wrote:
	>> I don't think this is enough of a
	>> problem to kill the feature though.
	>
	> I think this is a good feature to try and integrate into
existing APIs if
	> it's possible to do so cleanly.  I don't think it's worth
creating yet
	> another persistent storage API over, though.

	...

	> For
	> localStorage, we could add a origin-wide setting or add an
optional param to
	> setItem.

	Well, it seems harsh to require that *all* data on a domain is
either
	security sensitive, and thus need expiration, or not security
	sensitive and thus need none. I think it makes a lot of sense to
be
	able to let the page have several storage areas, some which
expire and
	some which don't.
	
	Think mail.google.com where storing my emails would count as
sensitive
	and should have expiration, but storing my drafts might be worth
doing
	longer to prevent dataloss.

	 

	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.)

	 

		I just thought of an alternative approach to this whole
situation
		though. We could add crypto and expiration functionality
to IndexDB. I
		know the crypto stuff has come up before and there was
some hesitation
		though. (Though I guess the same thing could be said for
		crypto+localStorage)

	 

	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.

	 

		> It seems as though expiration policies could be added
to the creation of
		> databases and the new FileWriter/FileSystem APIs
pretty easily.

		I don't understand the usecase of expiring files. Isn't
the whole
		point of saving to the file system so that the user gets
better access
		to it and so that things like iPhoto can index any
stored images?

		
		> But still....we need some use cases.  :-)

		I'm all for use cases. Though Nicholas did say that he'd
want
		encryption and expiration on essentially all privacy
sensitive
		information stored. Which I think I can understand.

	 

	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.

	 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100415/e2424661/attachment-0001.htm>

Received on Thursday, 15 April 2010 10:28:49 UTC