- From: Nicholas Zakas <nzakas@yahoo-inc.com>
- Date: Tue, 30 Mar 2010 14:06:23 -0700
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. -Nicholas ______________________________________________ Commander Lock: "Damnit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." -----Original Message----- From: dpranke@google.com [mailto:dpranke@google.com] On Behalf Of Dirk Pranke Sent: Tuesday, March 30, 2010 1:24 PM To: Jeremy Orlow Cc: Nicholas Zakas; whatwg at lists.whatwg.org Subject: Re: [whatwg] Proposal for secure key-value data stores 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 encrypted). 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). We can implement the required crypto in JavaScript, but should we have to? -- Dirk 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. > 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." >> >> >
Received on Tuesday, 30 March 2010 14:06:23 UTC