And then somebody emails you with a request to all of their data you have on them. Now you must respond to this email and you must figure out a way to find out whether they are who they say they are. Then you have to either refuse the request or extract the data and send it to them. Now repeat this x amount of times depending on how many people want to mess with you at the time.
What happens when spambots start using these requests?
If you find it hard to do that (have a defined way to recognise a customer; make a db lookup to get their data) then it's very simple you don't acquire nor keep that data. This means you have to have a level of competence - across your organisation (including how you store, retrieve data, and how you recognise customers) - before you start storing their data.
Really if you can't established a way to recognise customers how can we (as customers) expect you to competently do 2FA and competently store data without losing it.
It's like complaining that your kitchen shouldn't have to keep track of expiry dates of meat; if that's too onerous for you then you're showing you're not competent to run a kitchen.
ISTM the system you describe could lead to more data collection. I.e., a site like HN knows emails, pseudonyms, and posting history. What if they got a request like this from someone who claimed not to have access to the email they used to sign up? HN couldn't possibly comply.
Maybe that doesn't matter because posting history is public. One could easily envision another site that had some non-public data associated with email address, pseudonym, and no other PII. That site definitely violates the requirements you describe.
> ISTM the system you describe could lead to more data collection.
It really doesn't. What it does is attempt to gatekeep data (which these days is a huge risk) collection to organisations that are competent. You always have the option of not collecting data if you don't want to take that responsibility.
> What if they got a request like this from someone who claimed not to have access to the email they used to sign up? HN couldn't possibly comply
They wouldn't have to. If you're requesting your data from a company, you have to burden of proof that you are in fact the person about whom you're requesting the data. If you cannot prove it, you cannot get the data.
>Really if you can't established a way to recognise customers how can we (as customers) expect you to competently do 2FA and competently store data without losing it.
This is an insanely hard problem to do well. The recognition of customers is literally through which phishing attacks work. This is one of the most common avenues that people get access to systems and data they shouldn't. GDPR mandates that virtually every site needs to deal with this problem now.
Also, I'd say that reprieving all data on someone is not a trivial problem. Imagine you had a forum and somebody requests all of the data on them. However, another user has made a copy elsewhere on the forum with some notes about that user's personal data. Does the requester get access to that copy?
And now keep in mind that you complying is based on your understanding of a regulation that companies have spent millions on lawyers to figure out and still aren't entirely sure. And you have to follow this regardless how big or small your website or business is.
It's best effort. No regulator is going to fine you massively if you miss some data in an edge case like this. Worst case scenario, they'll tell you to do better in future.
I do see your point though, the intersection with phishing attacks is not something I'd considered in the context of GDPR.
However, as long as you provide a way for users with an account to download their data, you're 90% of the way towards compliance.
Again, unless you are FB or Google, the regulators will cut you some slack (just look at the lack of bankruptcies caused by GDPR).
Unless the text of the law is "the company shall try very hard (but if they miss a weird edge case they shall be merely sent a warning letter)", the GDPR allows selective enforcement. You note that it's already one rule for FB and Google, another for smaller companies. To what extent do you trust the courts to selectively apply the law in a sensible way, vs selectively applying the law in a harmful but legal way?
It's mostly the regulators who interpret the law and determine the remedies, as specified in the laws. In general, European regulators are aiming for compliance rather than fines, and I don't see that changing any time soon.
Most server applications are not designed for invasive laws like this. Think of all the HTTP servers that save IP addresses in log files, or all the mail servers that save user messages, IP addresses, and what not. Think of all the other kinds of software that save "personal data". Now think of the way companies backup this data. Do you think most companies out there have the infrastructure to automatically pull all information about a specific user from all of these sources? No way!!
Sure, a company the size of Activision-Blizzard can maybe pull it of, but the little guy has no practical way to be compliant. Not until GDPR compliance becomes a standard in server applications and backup solutions, and when is that going to happen? This is a serious problem that a few people among the elite have thrown at society without understanding the consequences, or caring about them.
And if you don't comply? Well, then this law is just another set of mines in the minefield.
I'm not really seeing the issue here. If the requestor is a user of your services, you presumably have some kind of id for them (like email).
Given that this is not a new law (2018 it became active), you would hopefully have some list of tables with information on users. From there it's select * from tables where user=blah.
Deletion requests are where you'll normally have more issues, but it's best effort. Again, look at how Facebook handle this. They explicitly state that it will take 90 days for all backups to be rolled out, and this is totally fine.
And if you are a small service, the likelihood of you having large amounts of PII on people across multiple services is pretty low.
It's worth noting that IP addresses which can't be matched back to a user are not covered by GDPR, so unless you've been storing every IP from which a user's logged in, then you'll be fine.
But, the real solution here is to only store data for which you have a need, and get consent for the processing which your service requires. Sure, this is harder than the normal YOLO store all the things, but it's probably better both from a storage and liability point of view.
Also, your argument segues from running a business of noteworthy capacity (who may have a problem complying) to small businesses (who won't have the capacity, but also don't store enough data to have a problem complying).
And to be fair, GDPR was npt imposed by elites, it was demanded by an awful lot of consumers in Europe. Maybe you don't like that, but I personally think that breast-feeding mothers shouldn't be censored. So cultural differences are going to cause both of us problems.
I don't agree that GDPR compliance is possible for the small guy. Let me explain why with the example of a small ecommerce business, consisting of one Wordpress site, a server host, a payment service and a delivery service. The user will interact with these 4 in some way. Now let's say a customer "Drek" decides to send support a message like the one I linked to, what are the implications for the company if they want to comply with GDPR using the current infrastructure? (Btw, all "Drek" ever bought was a pair of glasses, a purchase which he immediately regretted and asked a refund for after the purchase was finalized).
What happens? You say we need a (couple of) SELECT-statement(s)? I say we need more than that. Also, I'll tell you right now that doing a SELECT-query isn't something customer support can handle, this is something you ask from a developer or server administrator (== more wasted $$$$). So think about that while we go through the information retrieval process:
(1)-(3) You'll need select-statements, retrieval from log-files (such as access_log and error_log). Text explaining the data and explaining what it is used for. The data should be categorized and machine-readable in a common format. These requirements require a deeper understanding of the systems than just running a Wordpress site with a few plugins.
(4) "the recipients or categories of recipient to whom the personal data have been or will be disclosed;", that includes the payment, hosting and (possibly) delivery services.
(5) "where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;". Again, this requires extra knowledge.
(6) Since we haven't mentioned analytics services or any other privacy invasive service that knows more about the user than what they explicitly provide, this is not applicable in this example. However, it is still applicable for many real-world websites.
(7) Not relevant.
To be fair, the information retrieval can be automated, and a template can be used to compose a GDPR response. However, this does require the company to hire someone competent to do it, and also keep this process up-to-date so that it doesn't conflict with newer versions of Wordpress/plugins. And there WILL be newer versions because exploits are found on a regular basis. The developer will also have to make sure that the data is retrievable, and isn't stored offline or in an inconvenient format (such as the case with compressed logfiles). All of this costs money, and different solutions must be prepared for different systems. If the owner decides to move away from Wordpress to another CMS, he will have to hire someone to also replace the GDPR automation process.
This is not practical for a start-up, or a small business. Unless the infrastructure adapts (again, when?), people will have to write custom scripts/solutions to automate the process.
> And to be fair, GDPR was npt imposed by elites, it was demanded by an awful lot of consumers in Europe.
People are rightfully worried about their privacy, of course we are! But that doesn't give the elites the right to willy nilly impose (because that's what they have done) any solution without at the very least making sure it doesn't infringe upon other rights, and consult experts before writing the law. If they would've bothered to consult a seasoned and non-partisan server administrator, I think GDPR would've looked very differently.
I personally believe that the current infrastructure must change to respect user privacy, but this is not the way to do it.
And aaallll of this doesn't directly address the main issue, which is that the accumulation of laws has caused everyone to become a criminal in one way or another.
4 and 5 should already be covered by your privacy policy, which you can point at or copy paste from. Yes, you need to have thought about this once, but you've done that once and not when a customer asks hopefully! Ecommerce even has easy answers for why and how it is processing data most of the time.
The logfiles argument is generally overblown: the process for someone to establish a valid request for that isn't that typically that easy, and in most cases has the simple solution to not keep logfiles with personal data for long if at all (e.g. many webhosts already will by default or as an option anonymize IPs in logs, and it's not all that difficult to implement in other cases).
For business data, yes, you need to be able to look up customers and what data they've given you - but which business application doesn't allow that already?
I don't want to say it's trivial, but small operations tend to also have a small surface for this, easy oversight over everything, and can get this in order with an initial effort to design privacy policies (and identifying and cleaning up places they maybe were negligent before) and prepare checklists that make handling requests easy. I know plenty small shops that have done this just fine.
You know, you probably have a point on some of this.
Thanks, I may actually start building a WP plugin to help with all of this, as if it's the kind of problem you mention here, then I could probably make a whole bunch of money.
What makes you think that Reddit post actually created a significant burden for Blizzard, or that posts like this present a realistic threat to smaller businesses?
Not maybe. Same thing was proposed as a retaliation against other game companies as well. But Activision will just respond to all those emails with "Go to https://support.activision.com/gdpr"
Yes, it may be tricky. It requires some investment in the process. But unless you earn your money by exploiting user data, it's really not that hard to comply. The less data you keep, the easier it is. And the cost of compliance really scales with the company - for the wordpress with accounts from another comment you can do this manually on request. (likely you'll never need to)
> Not until GDPR compliance becomes a standard in server applications and backup solutions, and when is that going to happen?
> CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it.
> The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.
Which risks are “high risk”? They can always come after you for not consulting them and waiting 8-14 weeks for any feature launch.
> Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate[…]
No organization can objectively measure whether they’ve complied with this, much less prove it to hostile regulators.
> Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons...
I find it strange that you didn't quote the important part of the text here (high risk to natural persons).
Like, this doesn't apply to almost anyone. This applies to things like facial recognition or automated systems that track people's health data, not almost anything that one does in most CRUD/tech applications.
If you are subject to this requirement, then you almost certainly have both a legal team, and a data protection officer. Can you give me an example of what you think would be high risk but should not be?
Secondly, you're missing something here. I'm going to assume that you are US-based, based on your theory of regulation.
The US and EU differ wildly on how regulation works. What you would normally do, if your legal team/DPO says that what you're doing is high risk, is write an assessment (which your legal team has already done) and run it by your regulator. They'll say this works, or you'll need to do something different, you'll comply and get on with your life.
In any case, the whole process is really, really slow before any fines are administered. As an example, the ECJ basically said recently that data transfers from the EU to the US are illegal because of the NSA. The Irish regulator has just sent a letter to FB asking them to comply. FB are fighting this in court (with some ludicrous arguments), but as of yet their processing has not been impacted at all.
This legal fight has been going since 2011, and yet FB are still sending data to the US. I'm not sure if that fits the model of crazy regulators.
And let's be clear, as of yet there have been no GDPR cases fining companies for anything less than absurd violations. Ad tech still exists in Europe (and it's arguable that it shouldn't), FB and Google have continued on their merry way.
The second part is pretty much consult your lawyers/DPO and be able to make a case for whatever you're doing. In that sense, it's very similar to HIPAA, which doesn't seem to cause the same level of upset here.
I still stand by my original statement. If you have consent for your data processing, all will be OK (as long as it's not forced consent). If you don't have consent, or a legitimate interest in the data analysis/processing then maybe you shouldn't be doing the analysis or processing?
As an example, Facebook turned off automatic facial recognition in photos in the EU following an outcry. They re-introduced it when GDPR came in, because they asked for consent. You'll note that there have been no court cases on this, because it's totally fine.
tl;dr - get consent for your data processing, make it easy for people to get their data, and GDPR compliance is pretty easy. If you're in an industry where this is difficult/impossible, then lawyer up and be prepared to spend a bunch of money (and probably lose eventually).
Provide a way to get and delete user data.
Bang, you are now GDPR compliant.