Jacob Baytelman - Full stack developer, project manager, CTO
How To Code With The User Privacy In Mind
Just keep thinking about the data that belongs to your users as their data, not yours. As simple as that. Itís right and just and logical. If users post some content on your web site, itís their content. They have the right to modify it or delete it at any time. And when they delete it, it must be total, absolute, unrecoverable removal of that piece of data. No matter how technically challenging the implementation might be, you have to provide your users this option - a right to delete.
This means that you have to choose such tools, platforms, APIs, etc which allow true deletion. Thereís a problem with deletion in big data. Thereís a problem with deletion from backups. So be honest to your users and tell them, that Ďdelete a postí will delete their posts from the main database, but the posts will remain in the backups for, letís say, 2 weeks, because your backup cycle is 2 weeks.
Donít forget to create a table of delete requests and if you have to recover from the backup, use this table to delete from the recovered database. I know, itís an extra work
, extra effort, but remember, itís not your data, itís your usersí data and you have to treat it accordingly.
Minimize the data. Do not ask your users to provide info which is not absolutely needed for the functionality of your system. Do you really need their phone numbers and birthdays? I guess if you are developing the birthday greeting service you do need them. Otherwise you probably donít. I understand the plan to suck as much data as possible and then try to sell it, but from moral and ethical standpoints this plan is doubtful and according to GDPR it will be illegal in the nearest future.
Protect your usersí data. First of all, protect it from yourselves. Do you store passwords unencrypted? Why? So that you would be able to send the password to the user if he forgets it and asks to remind? A really poor practise. You should implement password resetting rather than recovery. Store passwords in MD5 or other unrecoverable forms.
Do the same for other pieces of information which you use for matching and not for searching. If your database is stolen, the damage will be minimized
Never store such data as credit cards on the server. Well, you cannot avoid it if you issue the cards, but if you simply use a 3rd party API for payments and pass them the credit card details, what on earth can make you store the numbers? For logging you can save first and last 4 digits. But why would you need to store the full credit card number? To make it easier for the users when they need to type it in again in the future? Leave it to their own choice and settings of the browser. Or if you are building a client application, ask usersí permission to store it, but store it locally, in the encrypted form and in the inner sandbox of your application, so that other apps would not be able to access this storage.
HTTPS is good. But itís not an absolute protection. Combine you own encryption and HTTPS.
July 11, 2016