Hacker News Reader

Comment by ColinWright | Hacker News Reader

Broadly speaking, and noting that IANAL, etc, etc, ...

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.

[0] https://gdpr-info.eu/

[1] https://gdpr-info.eu/recitals/

View on HN

> 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

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.

> might take up as much time as it would to learn a new language

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?

> 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

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

I think most people pro-gdpr never had to run a website.

TBH I suspect most of them have never run anything. I did an info session for a team of consultants, and was careful to include a lot of information on the positive intentions of the law, and every single one realized quickly that most of the costs of compliance for the vast majority of businesses had nothing to do with improving the state of privacy, and that for many business models that aren't abusing data this law is still going to be incredibly expensive.

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.

I think you're missing some categories. I've run websites. I consider myself pro-GDPR-spirit. But I also believe it should have explicitly phased down its effects on small organizations. If it gets tweaked back based on the observed effects, I'll consider that a win. If it is written in stone and remains as is for long enough to dampen entrepreneurship in favor of big deep pocketed organizations, it will be a huge loss. Right now it feels more like it will be the latter, but who knows.

> At one request per day ...

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.

You could have an automated report generator/emailer to deal with a), point the user to your privacy policy for answer to b), and finally again have an automated process for c) as well. This doesn't seem to be in the "learn a new language" effort ballpark to me. If you're handling user data for a side project, then you'd better be serious enough about protecting your users' privacy; if not, either remove the need to store any more data than is required to provide whatever service it is you're providing, or rethink your approach to starting a project in the first place.

And then they spend their entire free-time playing administrator on a service that doesn't make them any money. Time they could've spent on improving the service. The alternative is that if they're outside the EU they just block the EU and if they're inside the EU then they abandon the project.

> And then they spend their entire free-time playing administrator on a service that doesn't make them any money.

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?

If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while.

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.

> If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while.

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.

http://www.paulgraham.com/schlep.html

> How long will it take to respond to a request?

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.

(1) that you do it as a hobby has no bearing on your relationship with your users

(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

(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.

The problem is you have to do all that or face fines and lawsuits which is outside the risk envelope of most people's side projects.

Even if you're running a small side-project, you really should (a) not do things people don't expect, (b) be able to provide people with a copy of their data that you hold, and (c) delete their data if you're asked to (and you have no legitimate reason to keep it).

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.

Does it seem reasonable to you? Let me propose a scenario to you. Let's suppose that you commenting on Hacker News would mean that you must adequately respond to certain messages sent to you. If you don't do that then you can be fined. Does this sound like an environment that would encourage you to share your thoughts on Hacker News? Or does it sound more like an environment, where you would just not say anything and perhaps go elsewhere?

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.

My understanding is that if someone is not a customer, and I hold no data on them, then I can safely ignore any requests. At worst I can automate a response saying "I hold no data on you".

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.

> Once set up, these should not place a significant burden on the provider of a service

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.

not to mention that, historically and intrinsically, visiting a site or using someones application is a voluntary activity. no one is forcing the user to do anything and the user shouldn't be able to force the developers to do anything.

Try to build a treehouse without following legal guidelines and see what happens to your side project.

I frankyl don't understand why web site owners are entitled to a wild west, now-law zone?

Treehouse is an odd yet apt choice as the laws vary highly by municipality. None of the treehouses I played in as a child were inspected or up to code. I think the argument to be made here anyway is the level of danger. You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less.

> You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less.

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.

My entire, multi-year record of personal and financial information has been leaked and stolen at least 3 times, most recently from Equifax. In addition, certain of my passwords and financial and personal details were leaked at least a dozen times that I know about by various stores, restaurants, apps, and online forums.

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.

Big lurker, just created this to throw in my anecdote. I know of a person that was targeted with identity theft. They are current fighting it in court. It is weird how they have to prove to the system that it wasn't them who registered some vehicle somewhere and were involved in a hit-and-run(while they were even outside of the country through that period of time). That person owns a transportation company and could possibly get their license suspended. They were paid a visit by the sheriff because the debt collectors were not seeing their money (thankfully the sheriff was understanding enough, because it did look like they were going to be arrested until the court date). The name was not even written correctly! But since it is a SIMILAR name and at your address, it is you! Sorry for the rant, I just don't think the people that are going through this have the time or will to sit and describe their crappy situation. Is everyone who got their identity stolen supposed to run to the press? Run to Equifax's office asking for their reimbursement? If so, I wish they can spell it out more clearly to those who do end up affected. I think we will hear more about these stories eventually, after everyone who got burned clears their names of whatever they were burned for and have the patience to sit and explain how crap hit the fan, because they took out a loan somewhere and didn't understand the consequences. Even if GDPR isn't perfect right now, it is a step in the right direction. It sounds to me like the whole industry has been mishandling data until this point, that it makes it okay for people to complain that new players wont be able to come in and continue the same ways. Sorry if this is not the proper reply format, I hope it is ok to reply to anecdotes with anecdotes.

So your argument is that the unlucky minority can just get fucked?

My argument is that freeflight's apocalyptic image of the dangers of PII leakage and identity theft don't seem to match the actual experience of living in a country where PII leakage and identity theft are a norm.

The examples given were hardly "apocalyptic". And since there are accounts of all of them happening, it does seem to match the experience for some. Which leads me back to my initial interpretation of your comment.

Why shouldn't they have that option? You chose to visit that website and input your data. You are completely free to not go there.

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.

Is this why nobody actually builds treehouses for their kids anymore?

We still build just tell your kids not to let any EU kids in

> (c) delete it if asked, unless you have a legitimate reason to keep it.

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.

> 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!

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.

Reply on news.ycombinator.com