DEV Community 👩‍💻👨‍💻

Cover image for Clarifying GDPR
Rémy 🤖
Rémy 🤖

Posted on

Clarifying GDPR

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:

  1. What kind of personal data do you collect?
  2. 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:

  1. 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.

  2. 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.

  3. 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

  1. 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?

  2. 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.

  3. 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


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.


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.

Top comments (16)

jvanbruegge profile image
Jan van Brügge

The most important thing that I always see in the wild, is consent messages that have the trackers enabled by default, so pressing ok or consent will track you. This is explicitly not allowed. As this post says, you do not need consent for cookies necessary to function, but all tracking has to be opt-in. And the law explocitly says that having all checkboxes filled in by default does not count as consent!

george profile image
George Nance

So wait, does this mean that having Google Analytics on your page is against the GDPR is they didn't agree to it?

domysee profile image
Dominik Weber

If you have anonymizeIP enabled, then no, they don't have to agree. GA took precautions, they trim the IP on EU servers. Also they assure you (I think in their ToS) that they don't store the original IP address.
This means they don't have any personally identifiable information, and it doesn't fall under the GDPR.
What they can't ensure though, is that users store personally identifiable information in their events. So if you do that, you have to take your own precautions. Basically you should just stop doing that. Since afaik, GA doesn't allow selective deleting of data, so as soon as a GDPR delete request comes in, you'd have to delete all of your GA data.

jvanbruegge profile image
Jan van Brügge

The question is if your analytics collect personally identifiable information, such as IP addresses.

akashkava profile image
Akash Kava

The biggest problem with "Delete Data", users accidentally delete and then blame us for not being able to bring it back when users are not that tech savvy. This is even more complicated when their data is part of their communication with other users and they are all business transactions.

xowap profile image
Rémy 🤖 Author

You don't have to delete all of it and all at once. Or even to delete it at all. But it must be documented and based on the legal pretenses listed above.

Also the "contractual performance" can probably be invoked in some cases.

But yeah, it's a pain in the ass which is why you should think around it from day one of your product design and only merge "compliant" code.

akashkava profile image
Akash Kava

So finally, poor people cannot start internet startups anymore, it is only Rich people's game !!! That is truly GDPR. Funny thing is, poor person with no intention of stealing/selling personal data has to pay 30 millions in fine in case of some mishaps.. and Billionaire also pays 30 millions easily to steal personal data and get away with it.

Thread Thread
xowap profile image
Rémy 🤖 Author

Well not exactly. While internet giants are able to hide their data malpractices under undecipherable layers of bullshit, the cost for small companies is not so great. I work with a lot of startups and it's true that implementing GDPR afterwards is painful but if you have it in mind from the ground up that's pretty much invisible.

Also the big difference is that in addition to the fine, big violations become penal. Aka you can go to jail, especially if you're a large-scale CEO. So while fairness could be improved, it's a good step forward in my opinion (as a small company)

Thread Thread
akashkava profile image
Akash Kava

I don't believe any large-scale CEO will ever go to jail, Facebook CEO & Google CEO would have been jailed already if that was true, they will get out easily.

themainframech profile image
The Mainframe

It doesn't have to instantly delete everything when they click a single button - you can obviously send a deletion confirmation email and show multiple warnings that it cannot be undone.

anabella profile image

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.

This makes me so angry. Wtf does css have to do with data collection.

Amazing article. Thank you.

tobiassn profile image
Tobias SN

It’s honestly amazing how many site owners assume that they either just have to tell the user what they collect, make it take time to disable it, or serve a stripped down version to people who want to keep their data.

dploeger profile image
Dennis Ploeger


Thank your for this thoughtful and well written post. I've seen so much paranoid bullshit of people closing their blogs because of the gdpr and cursing it while the gdpr really is only for the people, not for bullying them.

Kind regards

bgadrian profile image
Adrian B.G.

A few months ago GDPR took the world by storm.

Hmm, I think that more then 70% of the new law already existed since 1995

As users we had most of these rights before, but noone care, like noone will care next year after the hype.

European Union to protect its citizens

From what I know the definition is broader, ANY person on EU soil is protected, the citizenship is not important.

ben profile image
Ben Halpern

Best GDPR post I’ve seen yet.

scooby359 profile image

Great article, thank you! I used to use the old UK DPA rules and was pretty confident with them, but still a bit fuzzy on how GDPR is has changed things. Thanks for the clarity and examples!

Find what you were looking for? Sign up so you can:

🌚 Enable dark mode
🔠 Change your default font
📚 Adjust your experience level to see more relevant content