5 ms·
> More generally, this is an example of "all regulation bad" thinking "any regulation good" is a fallacy as well, and just because data protection is a good th
by drchaos 9y ago
> More generally, this is an example of "all regulation bad" thinking
"any regulation good" is a fallacy as well, and just because data protection is a good thing, not all regulations claiming to achieve that are good, too.
And the GDPR is an especially bad and totally overblown regulation. I'd be totally fine with not being allowed to do bad things, since I'm not doing that anyway. I don't sell customer data, I don't collect PII from obscure third parties, I delete what I'm supposed to and I don't store what I should not.
Unfortunately, just not doing anything wrong does not help me at all, because GDPR requires basically everyone to be able to _prove_ , which -if possible at all- would take ages to implement properly. Sure, Google and Facebook can afford to spend a few man-years on this, and they can also afford a bunch of lawyers in case some obscure bureaucratic EU entity finds that they followed a wrong interpretation of the vague and unclear requirements in this directive.
As the sole developer for a small SaaS, I cannot afford that luxury. I can either write code, which earns me money, or I can write pages of pages of process documentation instead, which earns me nothing and does not even guarantee I won't be fined anyway, since who knows what obscure requirement may be hidden in those 201 pages of undecipherable legalese.
So my only realistic option is to do what most smaller businesses will do: Ignore the GDRP, and hope they won't come for me first. They probably won't, since they can't go after everyone at once. Sure, there's a rest risk, but hey, one can get cancer too. At least, if you get GDRP instead, you won't be dead, just broke.
- YeGoblynQueenne 9y agoI've worked for a few companies that handled clients' private information for financial purposes. There is a standard that you must observe if you work with payment cards, PCI-DSS. It is complicated and costly to implement in full, so some of the firms I worked for didn't - and instead avoided handling sensitive data that was subject to the strongest of protections specified by PCI-DSS. That meant, for example, never directly handling transactions and bouncing them off to PayPal instead. These were still successful companies, that kept growing while I was working for them. One company I worked for sold software for card transactions and so needed to get the highest level of certification. They did and they worked very hard to achieve this, which is why they were (and I believe, still are) highly respected in the business. They also did great financially and had big contracts with huge clients. There's also companies that specialise in that sort of thing- they help others get their PCI-DSS on. For a fee- but it's cheaper than doing it yourself, or paying the price of running wild with peoples' card data. There are many more options than "ignore the standard" and "drown under it" is what I'm trying to say.
- drchaos 9y agoWhile this approach is reasonable and practical for credit card data, I doubt it's possible (let alone practical) for most businesses to do the same with what the GDPR considers personal data. You'd have to avoid email addresses, names, postal addresses, phone numbers, ... - even in fields where such data is not even supposed to be, like comments or emails. Might be possible if one just sells ebooks or similar digital goods without much customer interaction. But for anything more complex than that, you're pretty much out of luck.