Hacker News Reader

Comment by ujkwast | Hacker News Reader

>GDPR threatens website owners with fines of 4% of turnover or €20 million (whichever is higher) if they do not jump through a number of ambiguously-defined hoops. The law, combined with parasitic no-win-no-fee legal firms, puts website owners at risk of vindictive reporting. Young websites and non-profits cannot afford legal teams. Therefore the risk posed by GDPR is unacceptably high.

I get the point about legal trolls,but how are the hoops ambigously defined?

- don't store data you don't need for your business' stated purpose

- get active consent before you do so

- be ready to delete data on command

- store the data with best principles (i.e., instead of having ID and other stuff connected, centralize identifiying information and protect,use pseudonyms otherwise)

IANAL, but this seems pretty sensible?

View on HN

He said the site does not make money. So why would he spend more of his time to make the changes needed to be compliant?

That said, I think the fear of no win, no fee legal firms is a little overblown. You can't get blood out of a turnip and if he's not making money there's no reason any law firm would be interested in suing him.

> He said the site does not make money. So why would he spend more of his time to make the changes needed to be compliant?

I'm honestly wondering what the law previously said regarding data protection. The Dutch WBP from 2001 already covers everything that he would have to do under GDPR given this website, so unless the UK has some very weird laws (or unless we're weird), nothing would change. Perhaps an extra tickbox on signing up that says "yeah yeah I'm really very aware that my data is shared with third parties".

Most likely, this is a good excuse to go "I refuse to read the long legalese [even if it's 95% the same as before] and I'm just going to quit this loss-turning website without the community turning sour on me because I have a good excuse".

The main difference is that you have to tell people ahead of time what you are going to do with the data and what lawful basis you are going to use to justify that usage. Later you can't change your mind. Additionally, you have to record what you have previously told people (so you can say, "On this date we informed you that we would use the data in this way, are we are doing so"). One other potential difference is that you need to be able to inform the user specifically with which 3rd parties you have shared the information.

Generally speaking, I think most sites will require some additional development work to update their UI and to store the data. If you have been compliant with the previous laws then it should be no problem. One wrinkle is that in the previous laws there was no way for your customer to find out if you were following the law or not (without suing you). With GDPR they have a right to both be notified what you plan to do and the right to request evidence that you are following that plan. There will be many companies that will have to alter their processes significantly to account for this.

It's very likely that the site is non-compliant with Dutch law.

I just mentioned the Dutch variant because I know of it and since both counties are in the EU, laws are typically very similar. I'm wondering if he was compliant with whatever the current (pre-GDPR) UK law is.

> I'm honestly wondering what the law previously said regarding data protection.

In the businesses I'm working with, I'm finding the biggest problems with GDPR aren't with GDPR - they're because the business wasn't compliant with the UK's Data Protection Act (1998). So the pain is the scramble to catch up.

He said the _site_ doesn't make money. He might make or have money from any number of other sources.

Should have incorporated to insulate himself then.

>He said the site does not make money. So why would he spend more of his time to make the changes needed to be compliant?

I think you could ask that question about all the other formalities you have to engage in as well if you run a business? Managing his taxes probably takes more time than making that kind of business GDPR compliant

I haven't seen his tax return of course, but perhaps he's not running it as a "business" at all. From the sounds of things it was a side project and could easily be classified as a hobby even if it were generating a little income.

Especially since gdpr doesn't allow individuals to sue, only regulators, so the fear is bogus in the first place

If I was a competing site, but which charged the user, I sure as hell would be incentivized to take down my competitor that is free.

> but how are the hoops ambigously defined?

Well, just in this thread, two people providing 4-point lists of _simple_ things that can be done to abide by the GDPR provide two different lists that they themselves are ambiguously defined.

So, perhaps it's not as _simple_ as you make it out to be.

I've noticed most people are not sure of what exactly they need to do to comply (me included). With the ambiguity, it seems the best way to cover yourself is to just be able to say you consulted a legal team in the past and did what they told you to comply. This has obvious costs associated with it.

Which only means for this particular site, shutting down instead of paying legal fees is a valid choice.

>- don't store data you don't need for your business' stated purpose

>- get active consent before you do so

These are mutually exclusive. The GDPR specifically warns against soliciting consent for collection and processing activities that are actually needed, as consent is not considered meaningful when the alternative is to avoid doing business. Consent is only valid if you can "degrade gracefully" in its absence. (I'm not a lawyer).

It makes more sense to ask for literally everything, and provide no feedback on whether the user should join or not until the next page. Literally everything. Even things they can't avoid sharing. Don't check it until the end - preferably several pages later. Then, if they didn't consent to a required thing instead of an optional thing (which should look identical), their entire setup process should be voided, with a great banner blaming European Regulation.

If you didn't check a required item, you're uncomfortable with a fundamental feature of the service, and shouldn't be using it at all. It seems like a feature, not a bug, that it's hard for you to override your values about privacy and use the service anyway. (But anyone designing for user engagement will be aware of this).

- deletion of data

Deletion of data from all external services that you use and internal services. If you have some processed data from internal data pipelines you will have to clear that as well. What about error reporting services? Internal logs? I think for data backups you can have it encrypted and that works as a good alternative but if you have to delete data from there it is not at all feasible.

- store the data with best principles (i.e., instead of having ID and other stuff connected, centralize identifiying information and protect,use pseudonyms otherwise)

Even if in the main data stores you store them in a well normalized way. It becomes a pain to do the same thing to do the same in data pipelines, sinks etc. If you are having a reporting DB it would make sense to denormalize data there.

Reply on news.ycombinator.com