- From: Dirk Pranke <dpranke@chromium.org>
- Date: Tue, 30 Mar 2010 13:24:10 -0700
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 13:24:10 UTC