[whatwg] Proposal for secure key-value data stores

[Dirk Pranke]

On Wed, Apr 7, 2010 at 2:14 PM, Nicholas Zakas <nzakas at yahoo-inc.com> 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.”
>
> 3. “That’s okay, we’ll just use the XYZ JavaScript encryption library.”
>
> 4. “And then use it on every read and every write?”
>
> 5. “Ugh, you’re right, nevermind.”
>

Presumably the "ugh" is a reaction to the perceived slowness of doing
the crypto in JS? Has anyone
benchmarked JS crypto performance compared to what the imagined C/C++
perf would be?

>
> I’ve had, or participated in, this conversation multiple times. I also know,
> from speaking with others about this proposal, that this conversation isn’t
> uncommon.
>
>
>
> 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?
>
>
>
> 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. 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.
>

It is true that not having control over your data could be an issue, but simply
embedding expiry into the data may not buy you much to protect it. Insofar
as the crypto wouldn't be running in a TPM, it would be easy to reverse engineer
it and extract the data; it would also be fairly easy to reset the
clock on the device
to keep data from being deleted.

I continue to think that the requirements for a secure storage API
that fit a wide
range of use cases are not particularly clear (and it would be easy to see this
balloon into a wide API designed for lots of different corner cases).
I think the ideal
approach for this would be to build a JS-based implementation on top
of the existing
libraries and, if such a library sees wide adoption, push for it to be
implemented natively.

If there are fundamental missing primitives, then by all means we
should look at adding
them, but I'm not sure that we are missing anything.

-- Dirk

>
>
> -Nicholas
>
>
>
> ______________________________________________
>
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>
> ________________________________
>
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jeremy Orlow
> Sent: Tuesday, April 06, 2010 6:55 AM
> To: Nicholas Zakas
> Cc: whatwg at lists.whatwg.org; Dirk Pranke
>
> Subject: Re: [whatwg] Proposal for secure key-value data stores
>
>
>
> Sorry for misunderstanding your original suggestion.
>
> On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas <nzakas at yahoo-inc.com>
> wrote:
>
> 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).
>
>
>
> 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.  :-)
>
>
>
> My proposal is less about encryption and more about providing better control
> over how data is stored and for how long.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> -Nicholas
>
> ______________________________________________
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
>
> -----Original Message-----
>
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dirk Pranke
> Sent: Tuesday, March 30, 2010 3:09 PM
> To: Nicholas Zakas
> Cc: whatwg at lists.whatwg.org; Jeremy Orlow
> Subject: Re: [whatwg] Proposal for secure key-value data stores
>
> On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
> wrote:
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> One way or another, I think JavaScript crypto is going to be important in
>> the next few years.
>
> Perhaps we should instead focus on a set of JS Crypto APIs, since that
> is largely orthogonal to the storage APIs?
>
> -- Dirk
>
>