➤Set a baseline for data retention ➤Almost nothing is secret ➤Using privacy as your guide is more productive than security ➤Privacy is a thing to be removed— sparingly—instead of given
uranium. Sometimes you can make money from it, but it can be radioactive, it's dangerous to store, has military uses, you generally don't want to concentrate it too much, and it's regulated. Why keep uranium you don't need? -Filippo Valsorda (@FiloSottile) Google cryptographer & security researcher
sensitive data ➤ application misconfiguration ➤ accidental public disclosure (e.g. committing logs or a key to GitHub) ➤ API exploitation ➤ Normal use of your application
users to delete most of their own data, and make it easy for them to do ➤ Really, truly delete it if you can ➤ No, don’t soft delete it. ➤ Yes, really delete it.
your database in your mind as a set of other people’s information, instead of “your” data since you wrote the application ➤ You should be user record #1 (in production) ➤ Add the personal info for every dev that works on the application ➤ Full names ➤ Address, email, phone numbers ➤ SSN or other sensitive identifiers
am not a lawyer ➤ You are not a lawyer ➤ Things to consider: ➤ Record retention laws ➤ Corporate policies ➤ If you can’t delete, consider (in order): ➤ One-way hashing ➤ Encrypting (reversibly) ➤ Pruning/limiting ➤ Archiving elsewhere (e.g. in an “old users” table stored not in the production environment)
hoarding is a natural tendency ➤ It’s not your data, it belongs to the user. Consider what actions they might need to take on your application and if the data is necessary ➤ SSN for background check, but delete when check is complete ➤ Birthday to authorize for mature content, but don’t store after checking
form of data that you might need ➤ Required in plain text ➤ Email, name, phone number ➤ Plain text, but ephemeral ➤ Tokens, sessions, server logs, app logs ➤ Stored one-way hashed ➤ Passwords, SSN last-four ➤ Never ever stored ever ➤ Plain-text passwords