GDPR for Developers by Example(blog.blether.chat)
blog.blether.chat
GDPR for Developers by Example
https://blog.blether.chat/2022/08/03/gdpr-for-developers-by-example/
99 comments
PII doesn’t exist in GDPR so certainly don’t start there. “Personal data” is the nearest equivalent, but that includes any data that could be aggregated to identify and individual and is consequently a wider concept.
You are certainly correct that the term PII never appears in the legislation but instead the focus is on the ability to identify someone.
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.
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.
These are technical controls - are you sure they're the right ones for your organisation - - or even needed? Organisations that comply with the GDPR typically employ a data protection officer - the person responsible for creating or overseeing the creation and ongoing maintenance of a privacy impact assessment. That feeds into requirements long before any code is written, let alone implementing other procedural or technical controls.
In theory I agree, in practice GDPR compliance is lots of poorly bolted on band-aid solutions to legacy systems.
agree with this. If done well, then this has all sorts of secondary benefits.
better engineered systems, more agility through implicit fire breaks, stronger devops processes, faster backups etc.
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.
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.
Why should established companies get even more of a head start on new players?
Establishment companies are always writing new systems or rewriting systems. They will be easy competition if they don't.
> Scenario: A user who has paid for a subscription then cancels it wishes their data to be deleted.
> Outcome: The information is not deleted as it is required to defend any possible future legal action.
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'.
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'.
Yes, you need to keep the invoices with the users name and address on it (and probably a customer record in the ERP system). But - for example - if you provide a service that stores a users portrait picture, you need to delete the portrait picture upon request. You don’t need that for a financial audit.
This is wrong on many of the early points so I didn’t finish it but:
- on financial information, you must delete everything not required for regulatory purposes if requested by the user.
- on logs, while there is a legitimate interest to be able to find logs related to a user to be able to help them in support cases you cannot keep that information indefinitely. And once a user requests deletion that need is no longer relevant.
> This is wrong on many of the early points so I didn’t finish it but: - on financial information, you must delete everything not required for regulatory purposes if requested by the user. - on logs, while there is a legitimate interest to be able to find logs related to a user to be able to help them in support cases you cannot keep that information indefinitely. And once a user requests deletion that need is no longer relevant.
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.
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.
Indeed, there is a legitimate interest in keeping everything relevant to payments and execution of contracts for the time period that contract exists and for the time period a party can sue.
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.
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.
> I've had multiple legal teams tell me that once they pay for something you need to keep everything.
Pay for Google Drive, delete some old pictures, "error cannot delete pictures since you purchased more space".
Pay for Google Drive, delete some old pictures, "error cannot delete pictures since you purchased more space".
Are we sure they don't just soft delete them?
haha, yea everything isn't everything.
"keep everything related to the contract/payment etc" this is not hard
Whatever about relying on legal advice for your own retention policy, it seems unwise to make sweeping generalisations packaged as guidance on GDPR For Developers By Example.
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.
>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.
I like this reply. Thanks for it.
> 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.
> 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.
And yet whenever the negatives of GDPR comes up in discussions someone is there to always ensure everyone that "don't X, it's just that easy". It really really doesn't appear to be that easy.
"Keep everything" is vague though. "Everything relevant to the transaction", certainly, as you've mentioned, that's already required by law. "Everything" as in "all user data including data they may have uploaded" will certainly not fly, even though it might help with defending against chargebacks.
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.
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.
> "Keep everything" is vague though. "Everything relevant to the transaction", certainly, as you've mentioned, that's already required by law. "Everything" as in "all user data including data they may have uploaded" will certainly not fly, even though it might help with defending against chargebacks.
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.
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.
Yeah, I'd be super careful with any advice from a lawyer that told you you can store _all_ data because of potential future litigation after your customer has ended the relationship and asked for deletion. I'm pretty sure it would explode in your face in a comically large way where you're not only going to lose the case, you're also going to be found to have been knowingly and willfully non-compliant.
"Judges hate this one weird trick" doesn't work, I'm afraid. Would love to hear which company follows that advise though :)
"Judges hate this one weird trick" doesn't work, I'm afraid. Would love to hear which company follows that advise though :)
It's not as easy as saying "there is an exemption", because courts ruled in many such cases and usually denied that argument, at least here in Germany and other EU jurisdictions I am aware of.
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.
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.
Even if you are allowed to keep data I wouldn't be surprised if you have to move it out of the production system. If I remember my lessons on data protection right then you have to restrict access to people that need it and in the case of legal issues the data has no reason to remain on your production servers but might be better locked away on an archival server with access limited to your lawyers.
> 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.
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.
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.
o_O
> 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.
> 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.
The more I read this blog post, the more it seems like a joke. Definitely wouldn't take it as any kind of legal advice.
That's correct.
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.
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 you and I would perhaps disagree on the definition of 'explicit', but if we put that to one side, what is the point of any data being stored at all if it is not possible to link it to an individual user?
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.
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.
To be clear, this example is clearly and explicitly in the context of whether or not consent to use cookies is required. Which it isn’t, if you aren’t storing cookies or cookie equivalents.
From section on local storage consent. For storing data in the cloud you only need consent to store their personal data. You can store non-identifying data within th cloud. For example you have a web game and you use javascript code that generates a session id randomly then you use that session id to store data about a game stats in the cloud. (Why you would do this I am not sure) You wouldn't need permission from the user to store the non-identifying data.
I see what you mean, but the statement is false as written. If it were 'You have an app that only stores non-identifying data in the cloud', then it would be correct.
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.
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.
Yea but then you need to be really careful not to let the user sneak in any PII anywhere; say a user sets their full name + address as their username; they can now request that you delete this data.
While you probably do need to expect to delete usernames (usernames are expected to be identifying), but the user sneaking personal data into fields where it isn't expect is probably out of scope as not part of a filing system anyway. Certainly I wouldn't expect a serious problem to punt it to "we'll deal with it manually on a 3-month turnaround if it becomes relevant" as long as you're not actively designing your systems to not be able to delete data.
Practically speaking, if you're using personal data in ways that GDPR demads consent for, you ... probably shouldn't be doing that. You can store data that you need for a laundry list of legitimate purposes without consent.
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).
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).
How about a high score table?
That is too simplified. At least the part about the right to delete the data. In my understanding it is not legal to keep all data because a user paid for a service. In German law you are required to keep the data for the invoice. But I am not a lawyer.
German lawyers told me that we were to keep all data. There is also an exception in the law for the need to provide abiltiy to provide legal defence. Which is mentioned in the blog but not in the examples. I'll an add an example so it clearer about that.
You need financial data of course, but you don't need a record stating I logged in 2 years and 5 months ago at 09:15 in the morning from an iPhone 8 from IP xxx.xxx.xxx.xxx and used your app for 12 minutes, I have every right to request you to delete that information as it is not necessary for legal defense (chargebacks) or lawful. You might be non-compliant by keeping that information actually.
From someone who is not a lawyer, but was responsible for GDPR compliance at a major hospital in Germany: You may want to switch your lawyers.
Someone who is not a lawyer but had to deal with our legal department more frequently than I wish: it absolutely depends.
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.
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.
That may have been true in your specific case, but that does not generalize.
I work for a German company and am responsible for GDPR implementation. I would not suggest following the advice in the article. It is full of mistakes and bad advice and would easily put you at risk for a law suit, at least in Germany.
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.
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.
Can you explain where the mistakes exactly are?
I took a look at their privacy policy and the company behind this blog isn't even GDPR compliant, despite their claims. Note the following from their privacy policy:
"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.
"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.
IANAL, but shouldn't a data deletion request also apply to the data inside backups, even when no recovery is planned?
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.
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.
The logs part made no sense, at least as I've always seen GDPR interpreted. It depends on what goes in the logs.
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.
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.
SHAs of entire IPv4 space can be easily precalculated. Include a nonce, that is rotated periodically, to solve this.
It's a good idea, but the hash doesn't need to be unique or secure.
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.
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.
> once a user has paid you the money, you need to keep their data. Their right to demand their data be deleted doesn’t matter as the other legal rights override it.
Crap, I paid Google $0.01 to activate my play store account.
Crap, I paid Google $0.01 to activate my play store account.
Is this person a lawyer?
No. This person sells a "GDPR compliant product", whatever this means. So they have an incentive to make sound as complex and cumbersome as possible so that you buy their product.
And ironically their own app is in violation of their own standards.
> 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
> 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
So, hows does the "Right to deletion" actually works in this scenario?
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)
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)
In that case, Company X would be the Data Controller and the request should be made to them.
The request can also be sent to slack as data processor. Most people don't actually know who is controller or processor and thus a processor has to relay the request to the controller who has to decide if the request is legit.
I would guess that actually anything you produced on company Slack is intellectual product that was produced during course of employment and as thus owned by the company. So no you can't ask it to be deleted.
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.
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 EU private messages are protected, companies can't just read through your entire mailbox as you have a reasonable expectation of privacy. Of course they can read it if they have a good reason: e.g. you're leaking information to the competitor, but you can't just read random emails between an employee and their spouse for no reason. (Article 8 ECHR).
[deleted]
I've seen the discussion here about "keeping all the data" and "delete as much as possible" for commercial purposes. IANAL, but I have worked around GDPR related stuff in more than one case, so here is my 50 eurocents:
- from the structural point of view: someone pays for a service. then cancels the service (in writing). then demands a deletion of content data(in writing). then ... chargebacks. Now in the court of law, how would the content data be of extra use, when the person clearly had used the service, cancled, and requested deletion?
- All the companies I worked with were more concerned with minimizing the retention of personal data, not keeping as much as possible. Storing unneccesary personal data too long is a recipe to generate fines much higher than any sum of chargeback, if brought to a court.
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/
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/
The website where the article was published does not comply with GDPR.
Lot of inaccuracy and wrong information in that page. I wouldn't recommend it.
My favorite hack when making static-ish websites: don’t set cookies, don’t use external content/tracking/fonts/cdns. Then you don’t need to show a cookie-banner and don’t have to fear it’s not correctly implemented ;)
GDPR - General Data Protection Regulation
This is way more complex that it is. Especially the cookie banner part. If you don't have global analytics (= google analytics) and if you don't have personalised ads, you're fine.
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...
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...
It's quite funny, you're saying I'm making it more complex than it is while everyone else is saying I'm oversimplifying it.
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.
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.
Lots of comments here about consulting an legal expert. If GDPR is so complex it requires legal advice, is it then fair to say the law is ambiguous and unreadable for the layperson?
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.
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.
Most laws are at least somewhat ambiguous and unreadable for the layperson. The gist of the GDPR is not particularly hard to understand and a lot of the complexity comes from covering obvious loopholes. In my opinion, the GDPR is not clumsily implemented at all (well, not within its text anyway). It's also deliberately technology-agnostic, to prevent a trivial loophole (Oh, I'm not tracking you through cookies, I'm tracking you through Biscuits™, totally different!) and that's one reason why a list of scenarios with clear-cut answers is not really possible.
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.
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.
> If GDPR is so complex it requires legal advice, is it then fair to say the law is ambiguous and unreadable for the layperson?
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.
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.
It's a lot less complex if you don't try to keep as much data as you can get away with.
That's the problem with every law: It's ambiguous to allow for super high forwards-compatibility like the introduction of completely new technologies.
For this a well-drafted law is not ambiguous, it is generic. Indeed, the more you go into specifics the more it opens the possibility of loopholes, but it should be clear what is allowed and what isn't, and how to implement any restrictions.
Thanks to EU,
now we have to confirm consent banners before going into any website.
now we have to confirm consent banners before going into any website.
Except for those sites that don't track you.
Try opening this website in a private session. Or GitHub.
Try opening this website in a private session. Or GitHub.
> While creating the cookie law, lawmakers understood that some cookies are literally required in order for the site to function properly. For this reason, they created exemptions that cookies that are functionally required don’t need to be consented to in order to be used.
Literally in TFA
Literally in TFA
No.
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.
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.
one question,
Who is responsible for the consent windows ?
Who is responsible for the consent windows ?
The developers that put them on the site.
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.
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.
Even when not required under GDPR, those banners may be required under the EU e-Privacy Directive (2009/136/EC ).
Even under the e-Privacy directive cookies strictly required for a website's technical functionality are permissible. Session cookies and such don't need banner.
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.
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.
> There is no need for them
I agree. They should undo the law that created an artificial need.
I agree. They should undo the law that created an artificial need.
It wasn't a law which created that need: many people don't want to be tracked even if there wasn't a law that banned you from doing so.
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).
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).
Imagine this argument for any other situation where consent is required. It's ridiculous.
[deleted]
Thanks to US we now have to Click I am over 18 when visiting porn websites.
The GDPR popups will appear only on websites that track you, and I found the first honest website so far bbc.news
they give you a clear reason and a simple way to opt out, not sure if it will appear for you , the message is
"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.
"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.
> 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
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.
> 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.
“Leak of IP Address Via Google Fonts Prompts GDPR Fine”
https://www.cpomagazine.com/data-protection/leak-of-ip-addre...
That is a stupid decision. Loading a page / resource from the web by itself should not be a gdpr violation.
Loading a resource submits your IP address to the server. If you query a server from company A you surely consent to it, if the website adds queries to company B's server it sends your PII to company B without your consent. Its especially bad when company B is Google, who operate on selling that data.
Oh no! Now everyone has to self host or Amazon will get all those IPs!
[deleted]
>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.
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.
Which is ridiculous because the PII funds the site.
No. https://www.theregister.com/2022/01/31/website_fine_google_f...
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.
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.
I'm so glad geoblocking the EU is so easy.
[deleted]
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.