GDPR for Developers by Example
blog.blether.chat
blog.blether.chat
A slightly more realistic approach I’ve seen to a lot of these issues basically boils down to:
- minimise PII collection as much as possible in general and start thinking of it more like a liability than an asset.
- Isolate the actual PII in your backend and stop passing it around from system to system.
- start working more with “references” to the PII data which is isolated and can be tombstoned when required.
It takes a little bit of thinking around the concept of “identities” and a deep understanding of how data flows through your various systems but getting on that early right from the point of collection makes life a lot easier.
What I’m saying is that by isolating PII as much as possible you can make that larger task much easier to achieve.
You can actually learn a lot from places you might not think of at first like how intel agencies and LE do things like source protection where you have to deal with the concept of a particular identity in a lot of different scenarios and different groups but it’s essential that the person remain unidentifiable at the same time to almost everyone. It’s a very similar set of problems and they have been thinking about this for a long time already.
I don't think GDPR should have been enforced on existing systems as in many cases it became a tick box exercise. Best practice and certification for new development would have made more sense.
Just to point out how dangerous this advice is; You are required to delete data on the user. You aren't required to delete data you need for legal purposes (your accounting department will need it for the tax office) and data you need to defend the legal claim (so delete everything but the data that essentially says 'User X booked Subscription A for N months'.
I've had multiple legal teams tell me that once they pay for something you need to keep everything. It's required to be able to mount a legal defence incase they want to do chargebacks.
And on deleting logs, the law literally says archival reasons. But also, there is a technical feasibility exception too. The legitmate interest for knowing what went on in your system for logs doesn't isn't just for helping the user. Knowing why there was a traffic spike, what happened in the past, etc is important to know how properly handle your business, this is a legitmate need for a company. Again, lawyers told me this.
For instance, in the UK one can sue on a civil matter for up to 6 years after the issue arose (and I believe same period for taxman to come after you) so it is perfectly valid to retain data for 6 years even if the user asks you to delete them. That does not mean keeping all the data you may have, though, but certainly names, addresses, payment details, order and shipping details (if relevant), complaint/support correspondence, can and should be kept. Then it gets trickier because arguably you can be sued over anything so there has to be a reasonable judgment call.
Pay for Google Drive, delete some old pictures, "error cannot delete pictures since you purchased more space".
For one thing, as with any legislation, simplifying it to a limited number of examples is guaranteed to lead to error by omission. I'm sure that you've noticed that when legal firms post guidance about the GDPR (and in private correspondence like you would have received in your own conversations with lawyers), they are never as definitive or absolute in their advice as this blog post is.
>And on deleting logs, the law literally says archival reasons.
Where in the Regulation are you referring to? Are you referring to archiving in the public interest?
> But also, there is a technical feasibility exception too.
There is no technical feasibility ("disproportionate effort"/"impossibility") exemption for the right to deletion. Whether a company can use such an argument as a successful defence has not yet been litigated.
> The legitmate interest for knowing what went on in your system for logs doesn't isn't just for helping the user. Knowing why there was a traffic spike, what happened in the past, etc is important to know how properly handle your business, this is a legitmate need for a company. Again, lawyers told me this.
To rely on the legitimate interest basis, you need to demonstrate that the processing is necessary to fulfil that interest and that it is balanced against the data subject’s interests, rights, and freedoms. It may be a valid basis, but it's certainly not definitive.
All in all, I feel that it may be better from all involved if you refrain from giving advice on the GDPR. I'm sure your lawyers will thank you.
> For one thing, as with any legislation, simplifying it to a limited number of examples is guaranteed to lead to error by omission. I'm sure that you've noticed that when legal firms post guidance about the GDPR (and in private correspondence like you would have received in your own conversations with lawyers), they are never as definitive or absolute in their advice as this blog post is.
You'll notice they never concrete advice on anything really. For the same reason no matter how strong your case is they'll always tell you that you might lose. Lawyers say lawyer things.
Logs are a very difficult issue in my experience. If you really want to be compliant, your logs will not contain any PII and you'll have compliance people check the infrastructure to make sure there's nothing going in.
Granted, a normal developer will typically not care about this, and once they're working on large enough projects where it becomes a thing, they'll also have sat through hours upon hours of lawyers telling them what not to do.
The last part about helping with chargebacks is the legal exemption that is to be used not to delete the data. You're entitled not to delete data in order to provide a legal defence to future cases.
"Judges hate this one weird trick" doesn't work, I'm afraid. Would love to hear which company follows that advise though :)
E.g. you cannot just keep medical records (unless you are e.g. a hospital and are required to safely keep that data) or dick pics either. Decisions about other less sensitive PII often haven't been made yet, but chances are the courts will not side with you but with the person whose PII is concerned.
What you can keep is enough information to identify the paid user in court (e.g. name and address data) and enough information to e.g. show you fulfilled your contract. E.g. if you're an email provider you probably can keep logs that show a paid user accessed your service and sent and received emails regularly, i.e. meta data about usage. What you cannot keep is e.g. the actual emails a user wrote or received or what contacts were in their address book.
Then, there are statues of limitations, e.g. in Germany usually 3 years for any debt disputes. Keeping data beyond that wouldn't be covered by exemptions, as the data would no longer be necessary to mount a defense.
Chargebacks are only actionable within a few months at most, so you could need to keep data during that period, but that would be short enough.
The GDPR requires for instance that you delete information from users that are inactive for a set of years (3 years ?). You wouldn't refuse to apply that on chargeback reasons for instance.
> Scenario: You have an app that only stores data in the cloud
> Outcome: No consent is required
> Why: You’re not storing data on the user’s computer but on your own computer.
That assertion is explicitly about the cookies consent if you look at the header to that segment. If you don't have cookies, you don't need that. As such, it's entirely correct in it's context.
You might still need a consent popup if you're tracking the user, but that's not the same as a cookie banner... Even though they can be combined.
I think there's also a big risk that there would be accidental data capturing.
In its context, and if you consider it in terms of the segment, and a literal reading, it's correct.
But I think there's an AWFUL lot of scope for someone to follow this advice and end up being on the wrong side of the law, and it's bordering on negligence to share this without a lot of disclaimers, caveats, and warnings.
That said, depending on how you code your app, you might end up logging user requests in a way that could end up causing issues by accident. You'd have to make sure that the unique identifier can't be matched up with an IP address in any way. I think the article is giving advice which is overgeneralised, and could very easily end up misleading its readers.
The consent provision is an escape hatch for incumbents with consent-tracking infrastructure to carry on doing (and raise barriers of entry to) mostly-illegitimate processing (and okay, the odd thing that might be reasonable but that the law hasn't considered).
In German law you are to keep any information regarding invoices for at least 10 years in their original format. This legal necessity usually overrides the right to delete. However, what this archiving of payment data entails differs based on how the payments are received/processed and how invoices are issued. The implications are different depending on when you pay cash, via a SEPA transfer or via a third party processor like Stripe/PayPal/Paddle.
But this whole debate is a perfectly adequate demonstration what the biggest issue with the GDRP/DSGVO is: it is extremely complex and intransparent.
EU lawmakers successfully implemented a law that makes it rather difficult for newcomers to enter a market with a (digital) product without putting themselves at risk or spending tons of consulting with a specialized lawyer. Despite repeated claims of officials that they intend to make the EU a more attractive location for digital businesses, their actions often speak different words.
If you are coming at this from any perspective other than "what is the minimum data I need to collect to run my service" then you aren't following the GDPR.
I've noticed that a lot of US based companies claim GDPR compliance but when you read their privacy policy, they clearly aren't compliant. The biggest violations come from what companies try to claim as "legitimate interest." Things such as analytics tracking, that are not tied to service delivery, are not acceptable under legitimate interest. Sharing my visit with Meta will never be legitimate interest. And so on.
"Research and analysis - We may process usage data and/or transaction data for the purposes of researching and analysing the use of our website and services, as well as researching and analysing other interactions with our business. The legal basis for this processing is our legitimate interests, namely monitoring, supporting, improving and securing our website, services and business generally."
This for of tracking requires consent. It cannot be justified as legitimate interest. Even this questionable blog post itself says so "Why: Because analytics is not required in order for the site to function."
edit: typos Their site never asked for my consent.
Edit: I am also skeptical about the logs part, I don't think logs can be a magical excuse to log everything that comes in, and should still only log "legitimate" use-cases.
If logs were exempt, it'd be really easy to just ignore GDPR by sticking everything in logs.
There is no magical GDPR fairy that prevents you from needing to comply with deletion requests because you've made your data formats awkward and hard to track/trace.
There are nice articles about how to anonymize log files so they don't need to contain identifiable information. For example, what is generally okay is storing part of an IP. If I just store the odd digits of the IP:
1) I'm probably okay for not being able to identify individuals.
2) I can do most analytics without issues. Unless I have bazillions of visitors, the identifiers are unique.
For nitpickers: Odd digits is a dumb hash for illustrative purposes. In practice, I'd run the IP through SHA, and store just the first few bytes -- enough that visitors are unique most of the time in my log files, but not enough to be able to meaningfully map back to a person.
The IPv4 space is 2^32. The trick is to keep e.g. 24 bits. 2^24 gives 16M possibilities -- unless your web site is _VERY_ big, that means it's a unique ID for most visitors. If you come across an IP (e.g. a scammer), you can also backtrack.
On the other hand, mapping back, you get 2^8 options, so you can't tie back to a unique user.
A nonce is a good idea, but it's not part of the security perimeter here.
Crap, I paid Google $0.01 to activate my play store account.
> Scenario: You want consent to use Google Fonts
> Outcome: You can’t include the Google Font CSS until you have consent
> Why: You don’t have consent to allow Google to process the IP, which is considered personal data
And the page for the service it connects to newrelic before I had a say.
edit: formatting
I have worked N years for company X and I was registered in their Slack workspace. Now I don't work for company X anymore, could I request Slack to delete all my data related to company's X Slack workspace?
Would that be a matter between Slack and myself only? Or perhaps between company X and Slack only? (at the end of the day I wasn't a paying customer, company X was)
EDIT: Now that I think more of it. This leads to somewhat interesting question about secrecy of correspondence. That is are the private messages protected? But on other hand would information posted on public or invite only channels be owned by company?
Probably depends on jurisdiction even inside EU.
In short: The minimization of data and its retention is the intent of the gdpr and I would suggest you work with it from the start, not with the ideas of lawyers "keep everything" because chargebacks.
An Example - with arguments for both sides: - https://www.burges-salmon.com/news-and-insight/legal-updates...
And some tracker with around 1500 cases and fines: https://www.enforcementtracker.com/
This person/company sells a "GDPR compliant" product. So they have all the incentive to make it sound a bigger deal and threat than it is. This way you will buy from them and accept the hefty price.
From my understanding, the issue with the Amazon fine, which they evasively mention, is that you could click on "deny" on their cookie banner but still be personally be tracked by amazon. [1] [2]
[1] https://dataprivacymanager.net/luxembourg-dpa-issues-e746-mi...
[2] https://www.laquadrature.net/2021/07/30/amende-de-746-millio...
Also, my understanding of the Amazon issue which I mentioned was they set the cookie before you accepted or rejected therefore the cookie was always set. Considering this is probably the most common mistake when it comes to cookie banners it seems fair to mention.
I really like the list of scenarios in the post. It is exactly what EU lawmakers should have published when GDPR launched. As often, EU tech-related laws are well-intentioned, but clumsily implemented.
A lot of tech involves interacting with data about people, so the software industry is affected by GDPR particularly hard. That's why you'll have a lot of people on a tech industry news website who may gave to consult a lawyer about the regulation.
Similarly, new traffic safety laws might have logistics companies seeking legal advice, health and safety regulations might have food companies doing the same or financial regulations might have any type of company ask a lawyer about the implications.
Besides, you might not be a layperson. There's a good chance if you frequent this website that you are a professional expert in different ways to store and use data for various purposes. In that case it might be a wise idea to take the time to learn your legal responsibilities with personal data to a slightly deeper standard than most people do.
That is indeed a big issue with the GDPR, IMHO. It is complex, not clear, and most people and even companies are not really sure what they can or cannot do and how to go about it.
now we have to confirm consent banners before going into any website.
Try opening this website in a private session. Or GitHub.
Literally in TFA
The are simple rules that say you can only collect data vital for delivering the service - anything else needs explicit opt-in.
Developers - not the EU - have created monstrous modal windows that assume consent unless you opt out.
Most of these would be unlawful under GDPR.
Who is responsible for the consent windows ?
There is no need for them if you are only using cookies directed needed for the provision of the site (as opposed to data gathering for advertising partners, for example).
Hope that helps.
However, including third party services or analytics and tracking can quickly prompt a cookie banner because those are not strictly necessary for a website to function.
I agree. They should undo the law that created an artificial need.
Normal people find it creepy and weird if someone (or something) knows too much. For example, I know a person who posted a photo of signpost on social media and explicitly challenged their friends to guess where they were, and even then they were disturbed when I posted a google street view link to that exact signpost 30 minutes later.
Showing them that Amazon searches for things they would not otherwise even look at resulted in adverts (for the specific product they looked at) appearing a few weeks later, was also something they found disturbing.
(As Amazon didn't get their explicit and meaningful consent for this use of their data, I assume they no longer do this, but I can't tell given my ad blockers).
"BBC.com would like permission to share your personal data with our ad partners to allow them to show you ads tailored to your interests"
Hope is OBVIOUS, they want to share PERSONAL data with random ad "partners", the popup would not be needed if their ads would not include tracking.
> Outcome: You can’t include the Google Font CSS until you have consent
> Why: You don’t have consent to allow Google to process the IP, which is considered personal data
Are you fucking high? Better not use a CDN then - they'll get the IP. Better not have any links - the users browser might prefetch, giving the link their IP. No embedding youtube or twitter. They'll get the IP.
This is beyond fucking stupid.
> Scenario: You only provide an ok button on your consent banner
> Outcome: You’re not compliant with GDPR
> Why: The user must be able to refuse consent
User can easily refuse consent - go visit some other website.
GDPR requires that you allow users to access services without giving up PII unnecessarily on an even footing with those who do willingly consent to being tracked.
You provide an "accept all tracking" button (eg "ok"), well you can provide a "reject all unnecessary tracking" button too.
You, the website provider, can easily not track users and not trade in their PII.
The inclusion of third party components on your website is your choice as a website owner. You have the responsibility not to leak data to Google.
Your consent workaround works if you do not collect any kind of personal data before the user clicks OK. As long as you get consent before enabling processing (i.e. you include Google Fonts or any other kind of GDPR incompatible third party) you're probably fine unless you do something particularly egregious.
"By visiting this site you agree to the terms" is useless though, unless you somehow show those terms before the site gets loaded.