On Wed, Oct 5, 2011 at 11:55, Nick Johnson <nickjohn...@google.com> wrote: > > Is potential usage of swap really relevant here, given what we've made > public about how we treat our drives? What is your threat model?
I want to minimize potential exposure of previously processed sensitive information in case of an appserver compromise. After all, appservers run arbitrary user-supplied code. I'm sure your sandboxing is good, but the risk is still high. Suppose some appservers are compromised on June 1 and are fixed on June 15. If sensitive data is only ever stored in memory, just the data that was processed between June 1 and June 15 might have been affected. If there might be any remnants of the data on disks, *all* previously processed data might be affected. And that's what I'll have to say to my clients. (If you won't tell us about the compromise, that's another story.) So unencrypted swapping effectively makes me unable to delete data permanently when it is no longer needed. mlocking() provides defense in depth. On disks information can live for much longer than in RAM. If sensitive data doesn't have to be stored on disk, we'd better make sure it never is. Alexander -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.