Jacob Baytelman

Building software since 1998

Innovations of Tomorrow Projects Contact me

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.


J.Baytelman July, 2016