- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 28 Jul 2010 01:43:34 +0000 (UTC)
On Tue, 6 Apr 2010, Jeremy Orlow wrote:
> On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas wrote:
> >
> > 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).
>
> 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.
I encourage anyone who would like a general crypto API to write one.
On Wed, 7 Apr 2010, Nicholas Zakas wrote:
>
> I've actually already seen a very common repeated pattern as it comes to
> client-side data storage:
>
> 1. "Hey let's try using localStorage to improve our user experience."
>
> 2. "Sounds great, but the data can't be stored in plain text if its user
> data."
Why not?
If you trust the client, then it's safe (by definition). If you don't,
then you've pretty much lost anyway (the client could just intercept all
communication as it happens).
If you're worried about cached data falling into the wrong hands but can
guarantee that:
- the client is secure until it falls into the wrong hands
- the client will have expired data securely before it falls into the
wrong hands
- the client has no stored passwords
- the client leaves no compromising data in RAM or in temporary
locations (e.g. the swapfile) on disk.
...then encrypting the data with a server-provided key in JS seems
reasonable, but is this really a situation that we can seriously expect to
happen?
> Again I'll say I'm all for adding crypto into JavaScript. I think in
> addition to that, there should be affordances for what will likely be
> common usage patterns. To me, any and all mechanisms for client-side
> storage should have some basic crypto built-in, so why not start here?
It's not clear to me what problem it solves. In most cases, it would not
increase security at all.
> In regards to data expiration, part of ensuring the security of data is
> knowing how long it will be stored on disk. If I let someone borrow my
> computer to check their email, and the email client happens to save some
> data onto the client, then that person's data will now be on my disk for
> who knows how long. That represents a data security issue.
For them or for you? For them, if they don't trust you, then they
shouldn't be relying on your computer in the first place. You could just
save their password, or their session cookie, or be logging all network
traffic and TLS keys as they're generated (and thus be able to read any of
the e-mails they saw even if they aren't stored locally), etc.
> By allowing an expiration date to be tied to the data, you can have
> reasonable assurance that the data isn't just going to be sitting around
> waiting for someone to try and use it.
We could add per-key metadata to localStorage relatively easily (basically
by having a parallel API that returns an object with the metadata instead
of the value). I recommend we wait until more of the new features are
implemented before adding more new features, though... we don't even have
a test suite for localStorage yet!
Having said that, it's not clear to me that expiry dates are especially
compelling, even from a security standpoint.
On Wed, 7 Apr 2010, Jonas Sicking wrote:
>
> 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.
If you're worried about data loss to that extent, I'd recommend whole disk
encryption and never suspending your laptop. Expiry dates aren't going to
save you much, especially for something like e-mail since you're
presumably going to always be using the mail client.
On Thu, 8 Apr 2010, Paul Kinlan wrote:
>
> 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.
What is the use case? Why is a JS library insufficent?
> 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.
>
> 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.
If it's made available to any page running on that domain, that means it's
available to any code on the machine, since the browser has to do the
decryption and isn't from the domain. So that doesn't seem safe.
You'd need at a minimum to have the server be the only agent that stores
the key for an extended period, and just have it pass the key to the
client when it loads the page, and not have it store it. (But then you're
still relying on the browser not caching that in any way.)
On Thu, 15 Apr 2010, Nicholas Zakas wrote:
>
> [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?
Write up a spec and get browser buy-in. :-)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 27 July 2010 18:43:34 UTC