- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Tue, 30 Mar 2010 20:19:13 +0100
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