Rémy 🤖A few months ago GDPR took the world by storm. As a result, everything still happens as usual but you got even more obnoxious and annoying cookie consent mechanisms. I'm by no means a lawyer but after talking about it with various clients let's assume that I have some understanding of what needs to be done.
We have cookies
First and foremost there is one very important thing that everybody should keep in mind. It's not about cookies. It never has been about cookies. Nobody cares about your cookies.
The question is:
- What kind of personal data do you collect?
- What do you do with it?
Put simply, yes you can collect someone's email to use as an identifier for authentication purposes but it doesn't give you any right to send promotional content to this address. It also means that nobody gives a crap about your bloody session cookies so please stop asking consent for "necessary cookies" it's total bullshit.
It's also worth highlighting that it's not the data itself but the process that you do with it. You can process the same data for several purposes and each one of them will need a justification of its own.
Consent culture
It's easy to get under the impression that you're going to have to ask consent for everything from here on, but that's not the case. There is actually six legal bases to process personal information. Here are the most notorious ones:
Legitimate interest. You need to weight the interest of this process for the user as well as for your company. If the user's interest outweighs your company's then you can legitimately process this data.
Contractual performance. Sometimes you need some data in order to perform the contract that you have with the user. Typically if the user buys something and pays with credit card you are allowed to use their credit card number to perform the payment.
Consent. The famous one. Basically if none of the other 5 reasons can apply then you need to ask the user's consent.
There is 3 other bases which are of course quite important but not nearly as frequently used
Compliance with the law. If you need the data to comply with the law then you're automatically allowed to process it. That makes sense right?
Vital interest. If collecting this data will directly save someone's life then you can use it in that purpose. Mostly useful for emergency services.
Public interest. Maybe processing this data is helpful for the public or maybe you are acting on behalf of the government.
I've been pretty quick on each point, you can get more details in this article.
Feature level
I've seem websites that basically give you two choices: either install a hundred trackers or give up on CSS and features. Well that is simple you are not allowed to do that. You can't justify penalizing a user that wants to keep their privacy, specifically because of reasons listed above:
- If you need the data for a given feature, it usually falls under the contractual performance or the legitimate interest cases [please note that "remarketing" is not a feature]
- Even if it doesn't, there is plenty of cases which are covered without requiring the user's consent
- Unless it's advertisement in which case it's not a feature and it's up to you to convince the user to give you their consent
In short there is no cutting down features due to GDPR restrictions.
Keep it clean
Each data processing must have an expiration date. Maybe it's instant, maybe it's never, maybe it's 3 years (lawyers often tend to agree that it's 3 years). But you need to make sure that every process keeps the data for a minimal amount of time and cleans it when not needed anymore.
To give a few examples:
- It's a good idea to delete inactive accounts after 3 years (unless you need the data to perform a contract)
- If you import a contacts file to invite your user's friend, it's best if you delete it right away
Portability
You should provide your users a way to extract their data from your company in one way or another, which would allow other companies to create an importer and work with your data.
Please note however that this only applies to the data provided by your user and not to the data that you produced afterwards.
Tinder exports are a pretty good example: you'll see your profile, description and all the messages you sent but you won't see your hotness score nor the messages you received.
Keeping track
Basically everything stated above was already in place one way or the other. GDPR just provides explicit instructions on what should be done and also levels up the sanctions for people not complying.
One thing that seems obvious afterwards but that didn't cross anybody's mind before is that you need to keep track of all your data processes in order to know everything that you do and inform your users about the use you have of their data. How do you know, even for yourself, what happens to the data if you don't have a central register for it?
Well GDPR now makes it clear. You have to keep track of everything, in a single file. To that usage, I drafted a YAML template that I include in every repository I work on. The idea is that with each pull request, the process is to analyze the new data flows and make sure they are present in the register. This is a good way to keep it up to date while also dealing with reasonable amounts of code to analyze.
There is no tooling yet but the idea of making it a YAML file is obviously to have a register "collector" that will be able to poll and merge all register files in all repositories. In my company we group repositories by client, that would be a good way to automatically provide to this client the documentation of their GDPR processes.
Who needs to comply?
Compliance is required by the European Union to protect its citizens. It means that any company in the world dealing with European citizens or operating in Europe must comply with GDPR.
This is important for European companies which import services from outside. By example if you buy a service from an US company (which as a tech company you always end up doing) you need to make sure that they are GDPR-compliant. Otherwise you don't have to right to export data to them.
Checklist
In the end, GDPR is more about accountability than a really deep change. We've been through the most important aspects of GDPR and this post is certainly not exhaustive. However I believe that this is already a better understanding that what you can find in the wild.
Let's keep things simple with a checklist:
- Make sure that you have a register for your processes, that is a documentation of all data processes and their justification
- If some of those justifications are based on user consent, make sure that you ask for it and that you can prove it
- Include in your UI a way for users to delete all their data (and routinely check it)
- Also include a way to do a JSON dump of all user-produced data
- Make sure that data which is not useful anymore is correctly deleted
- Make sure that all exported data goes either to an European company or a company stating that they are GDPR-compliant
- And please, please, stop asking for bullshit consent about required cookies and a zillion undocumented advertisement cookies
Once you do this, you'll be a lot further away from a Max(4% * revenue, 20 millions) fine and 5 years of jail time.
