W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2010

[whatwg] Proposal for secure key-value data stores

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 30 Mar 2010 20:19:13 +0100
Message-ID: <5dd9e5c51003301219q40ca243bl7e5c1c2b8e18cc9c@mail.gmail.com>
Most companies that have such policies enforce them with software that
encrypts your home directory (or entire hard drive).  Since most (all?)
browsers store such data within a users home directory, that should be
sufficient for the specific case you're mentioning.  (Well, except
for expiration.)  Note that home directory encryption is easy and free on
some Linux distros and Mac OS.  (I don't know either way about Windows.)

To be honest, if someone can get at _any_ of your browser data (LocalStorage
included) you have a pretty major problem.  So tacking something onto other
storage APIs doesn't really make that much sense.  If someone can get at
even just your cookies, they can probably do a lot of damage.

What are the use cases around expiration of data?

Lastly, we really should not be creating new APIs that are synchronous that
involve multiple top level windows (like LocalStorage and this API you're
proposing).  It makes it very difficult to achieve isolation and parallelism
between multiple sites.

J

On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas <nzakas at yahoo-inc.com>wrote:

>  Hi everyone,
>
>
>
> In attempting to use localStorage at work, we ran into some major security
> issues. Primary among those are the guidelines we have in place regarding
> personalized user data. The short story is that personalized data cannot be
> stored on disk unless it?s encrypted using a company-validated encryption
> mechanism and key. So if we actually wanted to use localStorage, we?d be
> forced to encrypt each value as it was being written and then decrypt each
> value being read. Because of this tediousness, we opted not to use it.
>
>
>
> Another major issue also relates to the persistence of the data in
> localStorage. Whereas cookies allow you to specify a time at which the data
> will be removed, localStorage is there more or less forever.
>
>
>
> It seems like any company that takes the security of its data seriously
> would run into the same issues, and rather than forcing every company to
> implement their own version of the same approach, a common native approach
> would be incredibly useful.
>
>
>
> With these problems in mind, and talking with a few other interested
> parties, I came up with a draft proposal for a client-side data storage
> mechanism that automatically handles encryption, decryption, and data
> expiration. I?d love to hear what people think:
>
>
>
> http://www.nczonline.net/blog/securestore-proposal/
>
>
>
>
>
> -Nicholas
>
>
>
> ______________________________________________
>
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100330/8212768f/attachment.htm>
Received on Tuesday, 30 March 2010 12:19:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:22 UTC