I never intended to make real money off it except maybe covering server costs if I'm lucky, but the time it would take dealing with requests like this it enough to scare anyone off.
I'm not sure what the problem is.
Your obligation is to keep the data secure, and only keep data that you need. Then you need to respond to requests to (a) tell a person what data you hold on them, (b) tell them what you do with the data, and (c) delete it if asked, unless you have a legitimate reason to keep it.
So if someone has given you data for the purpose of you providing a service then all you need to do is treat that data with care, don't do anything your customer doesn't expect you to do, and be able to provide and/or delete it.
Fair do, someone disagrees and has down-voted me. Please, having read the actual regulations[0] several times, including the recitals[1], I'd be pleased to see what's missing from that outline, so I can improve my understanding.
Over the course of a few years, doing these things might take up as much time as it would to learn a new language. For a side project, I’m not sure that’s a smart trade-off.
How so? Just build yourself a tiny tool that takes an email address or username and sends them their database entries along with the standard explanations about why you need that data.
For my side projects that will be around two hours per project and then 2 minutes for every request.
Or am I missing something?
You're assuming automated responses will satisfy requestors and, for the unsatisfied, be seen favorably by each of the twenty-eight national regulators, today and into perpetuity.
In any case, I got curious about your 2 hours / project + 2 minutes / request metric. One can achieve "basic fluency" in a number of languages within 480 hours [1]. We thus find a trade-off hyperbola [2]. For 1 project, after 14,340 requests you could have learned a new language. For 5: 2,820 per project. For 10: 1,380. At one request per day, that's under 4 years. TL; DR, even with optimistic figures, a significant toll is extracted purely for administration.
[1] https://blog.thelinguist.com/how-long-should-it-take-to-lear...
[2] 2 * Projects + (1 / 30) * Projects * Requests = 480
There's just a huge gap between people who viscerally understand making high-level business decisions and people who don't, and the vast majority of the writers and supporters of this law appear to be in the "don't" group.
There is where our expectations diverge. Do you really expect one request per day for a small side-project? Or even for a moderate start-up?
I find that astonishing. I admit I only have a few thousand users, but I've had a total of three requests.
Do you really think this is going to be a constant, relentless attack on your time? Do you really think that users of a service will constantly be sending DSARs?
I run a few closed services as side-projects totalling a few thousand users. I've received exactly three DSARs, and those are from people who wanted to see if I had processes in place. I'm very surprised that people think the administrative load will be significant.
But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000?
How long will it take to respond to a request?
Just out of curiosity, how long did it take you to respond to those requests?
>But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000?
>How long will it take to respond to a request?
I don't know, but I do know that there are plenty of developers out there that would probably have a lot of trouble adequately responding to these kinds of requests. Particularly the people who might have some trouble with English, especially the type of English in these requests. I have no idea how those people are going to handle these situations.
Anyone to whom you are not providing a service should not have any data released to them, so they can get a simple "I'm sorry, you're not a customer, and I hold no data on you." response.
Anyone who is a customer and is sending vexatious requests - I'd refund them if appropriate and terminate their service. Especially for side-projects, you don't need the aggravation.
In my case people were genuinely asking about actual data, and I took the time for the first to respond "by hand" - it took about ten minutes. The second time I documented what had been done the first, and parametrised it. Total time was about 15 minutes.
The third time I ran the script by hand and checked the output. Total time was under three minutes. I'm pretty sure that after another two or three I can just let it run automatically. Time taken for subsequent queries? Probably none.
And I agree that for some people, especially those for whom English is not their first language, would have trouble responding in English. It's not clear that they have to.
But speaking about time taken, I'm now going to bow out. I've made my position and understanding as clear as I can. GDPR is here, and everyone can make their choice about what they do to be seen to comply. I wish you all good luck.
We are talking about side projects. You do that as an hobby. Any minute spend on ANYTHING else than what you like to do is a minute lost for no meaningful reason.
(2) hobbies already cost time, money and effort, this adds a bit more to the time and effort factor, need not cost any money
(3) if you decide you can't operate your hobby and be legal then you always have the option to shut down
or
(4) you can shut off your service for Europe after removing all data on EU citizens that you have collected.
This is no different than any other regulation.
That all seems completely reasonable to me. It's certainly reasonable that a new start-up or side-project should use these considerations as part of their design, and I should think that an existing start-up or side-project that does not comply should look hard at why not.
If you think these demands are unreasonable, I'd genuinely be interested in knowing which, and why.
It's unreasonable, because it imposes an administrative cost on anyone that tries to do things on the side regardless whether they have good data handling practices or whether they have any intention of abusing the data. I would bet money on the fact, that JUST the fact that they must respond to a letter is enough to make some people go do something else. And who knows, maybe the side project could've been the next google.
For customers, how many requests would you expect? One in 100? One in 1000? If I store the data securely, and I only use it for the purpose it was intended, I can automate a response that (a) Sends them a copy of their data, (b) points them at the privacy policy saying I don't do anything unexpected with their data, and (c) offer a link to delete their data.
Once set up, these should not place a significant burden on the provider of a service.
I suspect we are arguing about how much work will be required. I'm saying that once set up, the administrative overhead is negligible, you are saying it isn't. Certainly the services I run have seen no increase in administrative load, I'd be interested to know who has seen a significant increase (once already set up) and why.
You're counting on an automated response mollifying users and being seen as reasonable by each of the EU's twenty-eight regulators. Perhaps that is true.
If so, a reasonable regulatory regime was produced. If it is not, or it is for a while and then one country decides to go ape shit, this was a bad law. Until we have more data there is regulatory uncertainty. Within that uncertainty is risk. That risk is unreasonable for non- or low-revenue generating projects.
Moreover, there is more precedent for such regulatory regimes becoming more, not less, onerous over time. That leads to incumbency bias, since Facebook and Google no doubt already have lobbyists for each of the national data regulators.
I frankyl don't understand why web site owners are entitled to a wild west, now-law zone?
That's a very dangerous sentiment to have. Identity theft is a very real thing. You can do pretty horrible things impersonating other people, things that will lead to people ending up in jail, things that can ruin whole families and drive people into poverty, desperation, and suicide.
It opens people up to blackmail, manipulation and a whole list of other, rather nasty, tactics.
On the extreme end, there's also the fact that not everybody lives in a "free country". In many places saying the wrong things, even online, can have very final consequences. In such cases, you not taking proper care of your user's data, sharing or leaking it all over the place, can result in people vanishing in some torture dungeon never to be seen again.
The consequences to me, personally? Not much. I haven't been blackmailed, I haven't been impersonated, jailed, or driven to suicide.
And in this, I am not unique, not unusual. Probably at least half of the adult US population has had all their information leaked just like mine was. The overwhelming majority of them suffered few to no consequences.
Adding legal costs like this de-incentivizes website owners which is now causing websites to shutdown EU access which I don't like.
I don't get why the EU thinks there are entitled to get content from the web while not abiding by the business model for targeted advertising companies.
Deleting it if asked might be neither cheap nor possible, depending. What if he has an audit log in his system recording that foo@bar.example attempted registered, baz@quux.example wrote a record &c.? If the audit log is a secure audit log, it's not possible to mutate a record after it's written — but that's exactly what the GDPR requires!
So now he has to either allow his audit logs to be mutable (and thus no longer secure), or he has to e.g. use an opaque identifier for his users, which means he needs another database, his audit-log–viewing system has to perform joins between the logs & that database (which means that it will no longer be straightforward to view with tail(1) & friends), that join has to handle deleted users in some useful way, &c. &c. &c.
That's thought he has to spend on something he didn't have to previously. There's obviously no problem with that in the case of something that's essential (and several provisions of the GDPR are essential). The problem is when the GDPR is mandating something inessential, or — in the case of its mandate that users be permitted to rewrite history — outright wrong. He's being forced by the law to implement a misfeature.
It's somewhat similar to a law mandating key escrow: it imposes engineering cost to achieve a wrong end.
My reading, and the advice I've seen in multiple locations, is that in the case of immutable audit logs (and backups, for example), being immutable logs (or backups) would count as a legitimate reason to retain the information. It would be required to store the logs and backups securely, but that should be done anyway.
The requirement would then be to delete what's possible (which is what the GDPR says) and then not process whatever remains. In other words, it's mandating what is already good practice.
Can you not just have a checkbox that says "I agree not to use this service from within the EU." or something like that? Like, I don't even track IP addresses for my dumb side projects. I wouldn't know where to start with this.
> One requires transparency in gathering and using data in order to allow EU citizens to exercise their rights to personal data. Therefore, the General Data Protection Regulation sets forth a variety of information obligations.
American citizens don't may or may not have rights under GDPR, or may have rights only where the processing is done within European borders, but European citizens have rights under GDPR regardless of where they are.
If its client side encrypted its not Personaly identifiable information.
https://ico.org.uk/for-organisations/guide-to-the-general-da...
Is a good starting point. Yes, you can refuse a request if it does not qualify but in this case there is more than enough meat to take it serious.
https://ec.europa.eu/info/law/law-topic/data-protection/refo...