**Disclaimer I am not a lawyer. Even though I cover what I have discussed with a lawyer in part, it doesn't represent legal advice. I point you in the direction of the ICO website. https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/
This article will cover quite a lot of ground relating to GDPR, privacy policies, and data security in relation to online activity. I am not an Information Security professional either.
If you are a company or legal practitioner who wants to explore security technology solutions, please get in touch here. Contact Info Rhino . This article presents three methods to secure your websites and protect your users. Each of these solutions is between 2 weeks to a few month's worth of development. I would be interested to hear of people willing to team up on this or buy these solutions if they are concerned about their user's privacy.
Why am I thinking about GDPR? Why are so many companies not ready for GDPR?
Through my Limited company Info Rhino Limited - I have been working on many applications with an online bias. Normally, I consult in companies where there is sensitive data held in databases and other systems. There are many cases where people have gleefully caused companies a lot of cost by demanding their personal data is removed. It really is a can of worms.
There are so many area where GDPR completely stops what seem to be normal practices. Getting an employer's reference for one.
A new referral scheme for Customer Relationship Management
It is well known that referral schemes are a very good way to win business. Former customers or people who may have seen your company may think you are a good fit for somebody they know. To me, it seems natural to reward that in some way. Word of mouth in a more technical scheme.
Currently, I am building the data model needed to adequately handle the "Right to be forgotten". The immediate thought is - hell, this is complicated! We need to encrypt data, tokenise data, allow data to be erased but tracked, and potentially - expire data after a certain amount of time.
Reading through the ICO website, there is quite a lot of wriggle room. If you write a sensible GDPR policy, you can make a good reason to have to remove data and you can charge people a small fee to remove their data.
The biggest risk to GDPR is the fines which can be administered if sensitive data is stolen. The most obvious two ways of doing this is;
- SQL Injection.
- Knowing a cloud's database password and location.
- Gaining access to the server, downloading the database and viewing the data.
One thing I don't do is store passwords. This is a good thing, as it prevents a database being stolen with emails and passwords which may allow hackers to gain access to other websites.
One potential way to avoid data theft
I won't go into the details of this article, but they propose having a key store and an encrypted form of a key store. https://medium.com/google-cloud/keeping-secrets-in-asp-nets-appsettings-json-5694e533dc87
I still think this approach is fundamentally flawed, because it relies upon trusting the administrators/hosting provider of the server.
Taking a sensible approach to not falling foul of GDPR and people's privacy
I had a quite involved series of discussions with a solicitor who has been heavily involved in researching and advising on GDPR compliance. The main issue is - most lawyers and policy makers live in ivory towers. It is easy to present scenarios which completely messes with their theoretical view of the world. I will present one now.
The accidental email address
GDPR experts will tell you that an email address is personal data. Even if this email address is all over the place, if somebody asks you to remove their email address from your database - you must. This is an immediate red flag to a technology expert because we know it is easy to spoof an email that looks like it is from a trusted sender (DMARC helps prevent this). It is also possible to complete a web form and intercept the http response through man in the middle attacks.
If you present the accidental email address scenario to a GDPR pro - they will say, ahh, but you have to remove it. On this point, I don't agree. Your system has been abused, maliciously and running a business is hard enough without spending significant amounts of time and money to deal with this. At the same time, if you were a shop storefront and there were illicit photos of a customer on your window - you would have to take them down. It is not clear cut.
The three ways we can solve GDPR and data security as a software developers
These are being built into our Content Management System. This is because we do want to protect our users. Our current solution only stores encrypted email addresses - no passwords. There needs to be a more comprehensive approach to security, and whilst our approach is way ahead of what WordPress and other platforms does - we see there being a big market in doing this right.
Method 1 - Obfuscation
We have seen the spy movies, where the escapee attends a rally were everybody is wearing a Father Christmas outfit and he dresses as Santa. Here is how it goes;
email@example.com joins the site. Upon joining, simply add firstname.lastname@example.org email@example.com firstname.lastname@example.org etc.
To make it more interesting, as you get unusual domains, add those to the seed list, so they can be randomly assigned to email accounts. At the end, you would know that some people may have been on your site.
Method 2 - Encryption and Tokenisation
This is my current preferred method, as it balances anonymity and the ability to use decrypt emails, but can offer right to be forgotten. I won't fully detail how this works, but in practice.
- When receiving an email address. Immediately encrypt it and tokenise it.
- Require that address to be verified.
- Everything related to that email address is linked to the hashed item.
- If a user insists on their right to be forgotten. Simply blank out the encrypted version of their email address. You can still store the hashed version of their data because that can prove to be a useful measure of potential site abuse and customer behaviour.
- If a user rejoins the website, we could decide to create an alternative data hash.
This method is pretty secure and tries to uphold the right to be forgotten. If somebody got access to the decryption key, the server, the physical database or connection details the website could be hacked.
For this reason, I tend to think these solutions should be non-sensitive in nature. For example - would people being active on my property website www.findigl.com be of that much interest? Not at all. Would people registered on a dating website be sensitive? Absolutely.
Method three - Remote storage of user data
Identity Providers and OAuth are perfect examples of this. You register on an external account and they handle the authentication. There are many reasons why individuals don't like doing this, despite it being a more secure way for the user. The main reason is privacy.
My approach is similar except you hold a security store remotely and your operational data store elsewhere. The remote data store is simply a list of email addresses, encrypted.
When a user "logs in", they are entering their email address on the secure server along with the source website. This source website is never stored on the secure server, but returns a token to the source website and an email with a url with the token to source website. The user clicks on the token and then has access to the source website.
This could be combined with obfuscation, but we would end up with multiple source website users and wouldn't even need to worry about the source website getting hacked. Everything is just a meaningless key.
Summary on maintaining security for your users
It seems the most important thing to do, is to have a GDPR policy - mainly to account for why you are doing things the way you are. Definitely consider a fair handling fee, but not as a means to profit from it and be aware that people's email addresses can be randomly generated ending up in your systems. There cannot be accounting for individual fruit loops who may join loads of websites and request to be forgotten, so there does need to be a way to block certain addresses.
If you feel like you want to take advantage of our current efforts on improving online security - please look us up at Info Rhino Limited.