8 ms·
GDPR for Developers by Example
- funcDropShadow 4y agoThat 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.
- that_guy_iain 4y agoGerman 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.
- funcDropShadow 4y agoThat may have been true in your specific case, but that does not generalize.
- beidnnwuudu 4y agoFrom 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.
- moooo99 4y agoSomeone 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.
- markus92 4y agoYou 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.
- danwee 4y agoSo, 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)
- closewith 4y agoIn that case, Company X would be the Data Controller and the request should be made to them.
- number6 4y agoThe 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.
- Ekaros 4y agoI 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.
- markus92 4y agoIn 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).
- zazazache 4y agoThis 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.
- that_guy_iain 4y ago> 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.
- luckylion 4y ago"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.
- deleted 4y ago[deleted]
- secondcoming 4y agoIs this person a lawyer?
- acatton 4y agoNo. 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.
- mimsee 4y agoAnd 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
- acatton 4y agoThis 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-million-gdpr-fine-to-amazon/ https://dataprivacymanager.net/luxembourg-dpa-issues-e746-mi... [2] https://www.laquadrature.net/2021/07/30/amende-de-746-millions-deuros-contre-amazon-suite-a-nos-plaintes-collectives/ https://www.laquadrature.net/2021/07/30/amende-de-746-millio...
- that_guy_iain 4y agoIt'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.
- m00dy 4y agoThanks to EU, now we have to confirm consent banners before going into any website.
- ben_w 4y agoExcept for those sites that don't track you. Try opening this website in a private session. Or GitHub.
- Angostura 4y agoNo. 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.
- m00dy 4y agoone question, Who is responsible for the consent windows ?
- Angostura 4y agoThe 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.
- beidnnwuudu 4y agoEven when not required under GDPR, those banners may be required under the EU e-Privacy Directive (2009/136/EC ).
- jeroenhd 4y agoEven 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.
- AndrianV 4y agoThe website where the article was published does not comply with GDPR.
- cplli 4y agoIANAL, 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.
- blagie 4y agoThe 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.
- atmin 4y agoSHAs of entire IPv4 space can be easily precalculated. Include a nonce, that is rotated periodically, to solve this.
- blagie 4y agoIt'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.
- d1sxeyes 4y agoo_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.
- that_guy_iain 4y agoFrom 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.
- DarkWiiPlayer 4y agoYea 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.
- naniwaduni 4y agoWhile 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.
- happymellon 4y agoHow about a high score table?
- naniwaduni 4y agoPractically 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).
- mhoad 4y agoA lot of not great advice in here. 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.
- robin_reala 4y agoPII 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.
- mhoad 4y agoYou 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.
- gghhzzgghhzz 4y agoagree 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.
- vanilla-almond 4y agoLots 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.
- mytailorisrich 4y ago> 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.
- account42 4y agoIt's a lot less complex if you don't try to keep as much data as you can get away with.
- solarkraft 4y agoThat's the problem with every law: It's ambiguous to allow for super high forwards-compatibility like the introduction of completely new technologies.
- mytailorisrich 4y agoFor 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.
- bitofhope 4y agoMost 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.
- kappuchino 4y agoI'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/data-protection/14-million-euro-fine-issued-for-improper-data-retention https://www.burges-salmon.com/news-and-insight/legal-updates... And some tracker with around 1500 cases and fines: https://www.enforcementtracker.com/ https://www.enforcementtracker.com/
- fooblat 4y agoI 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.
- zufallsheld 4y agoCan you explain where the mistakes exactly are?
- fooblat 4y agoI 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.
- zaarn 4y ago> 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'.
- andix 4y agoYes, 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.
- pestatije 4y agoGDPR - General Data Protection Regulation
- smeagull 4y ago> 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.
- deleted 4y ago[deleted]
- eli 4y ago“Leak of IP Address Via Google Fonts Prompts GDPR Fine” https://www.cpomagazine.com/data-protection/leak-of-ip-address-via-google-fonts-prompts-gdpr-fine/amp/ https://www.cpomagazine.com/data-protection/leak-of-ip-addre...
- muro 4y agoThat is a stupid decision. Loading a page / resource from the web by itself should not be a gdpr violation.
- deleted 4y ago[deleted]
- blueflow 4y agoLoading 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.
- 4y ago
- mrfumier 4y agoLot of inaccuracy and wrong information in that page. I wouldn't recommend it.
- amelius 4y ago> 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.
- andix 4y agoMy 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 ;)