[whatwg] Proposal for secure key-value data stores
dpranke at chromium.org
Tue Mar 30 13:24:10 PDT 2010
Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
Hence they cannot enforce anything like "use FileVault".
If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.
Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> 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.
> On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
>> 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:
>> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>> Morpheus: "My beliefs do not require them to."
More information about the whatwg