6 ms·
I always felt the GDPR was this kind of law. I'm not sure if it's even possible to be fully compliant.
by jmnicolas 6y ago
I always felt the GDPR was this kind of law. I'm not sure if it's even possible to be fully compliant.
- disgruntledphd2 6y agoDon't use information for any purpose you have not gotten explicit permission for. Provide a way to get and delete user data. Bang, you are now GDPR compliant.
- Aerroon 6y agoAnd 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?
- pbhjpbhj 6y agoIf 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.
- jessaustin 6y agoISTM 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.
- pilsetnieks 6y ago> 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.
- wlll 6y agoYou are allowed to require proof of identity before you hand out data. That might be as simple as requiring someone to log into their account (as you can already do on HN) to sending them a confirmation email, or other. > 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. No, and nor should they. > One could easily envision another site that had some non-public data associated with email address, pseudonym, and no other PII. "Dear requester, please log into you account and use the "request my data" link on your account page" There's a few things written about this around the web: https://law.stackexchange.com/questions/28998/right-of-access-by-the-data-subject-if-the-ip-address-is-the-only-personal-dat https://law.stackexchange.com/questions/28998/right-of-acces... > 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.
- Aerroon 6y ago>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.
- disgruntledphd2 6y agoIt'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).
- strken 6y agoUnless 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?
- disgruntledphd2 6y ago
- ordo_inf 6y agoYea sure buddy, that's easier said than done. Good luck running a business of any noteworthy capacity and getting requests like this: https://www.reddit.com/r/hearthstone/comments/df0zx5/upset_about_blizzards_hk_ruling_heres_what_to_do/ https://www.reddit.com/r/hearthstone/comments/df0zx5/upset_a... 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.
- disgruntledphd2 6y agoI'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.
- erik_seaberg 6y ago> 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.
- disgruntledphd2 6y agoHere's Article 35: https://www.privacy-regulation.eu/en/article-35-data-protection-impact-assessment-GDPR.htm https://www.privacy-regulation.eu/en/article-35-data-protect... > 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).
- disgruntledphd2 6y agoCool. I've never been downvoted this much before. Thanks for the new experience :)
- marcrosoft 6y agoNot to mention the EU thinks they can police the world.
- londons_explore 6y agoI'm all for someone else trying to police the world... I've had enough of one country having too much influence worldwide...
- justaguyhere 6y agoWho though? The alternatives are just as bad or worse ...
- londons_explore 6y agoI'd prefer to be in a battle of multiple world-policemen. I'd like local law and international laws from foreign states to conflict sometimes. I'd then like my local government to protect me from the foreign government when I (inevitably) break one set of laws. In turn, that reduces the effectiveness of world-policing
- sosborn 6y agoThe irony of course is that it leads to more situations where there are too many laws to track. Not saying your comment is wrong or anything, it’s just a funny side effect.
- lenkite 6y agoOk, so how do you police a super-power like China ?
- jmnicolas 6y agoIt's a pipe dream: they're weak (no army) and disunited (as COVID response showed).
- Barrin92 6y ago