Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: What does GDPR mean for banning users?
17 points by japhyr on April 30, 2018 | hide | past | favorite | 19 comments
It's been interesting to read about the impact of GDPR on sites of all sizes and purposes. Let's say I have a site where people can write and share math problems. I have a simple policy stating that any problem that directly or indirectly harasses anyone or any group will be flagged and deleted, and that repeated behavior like this will lead to banning.

Say a user gets banned. They then ask me to remove all information about them from my site. Am I allowed to keep any information that would help me keep this person from starting this cycle all over again?

What impacts will GDPR, and other data retention policies like it, have on the issue of moderation?



Yes.

You then clearly have a "business need" (banning troublesome members), that clearly allows handling and storage of data. Hence "right to be deleted" does not apply any more (or more correctly, it is overruled by a more specific right)...

I work with a bank. They have a general 3 or 6 month rule for "non customers" and "ex customers" (i.e. 3-6 months after you are not a customer anymore you will be deleted by normal retention).

If you are fraudulent, the retention interval is now 10 years! They have a full-time DPO who has spoken both to external legal council (he is a legal-trained person himself) and our local DPA.


For those reading along, it’s article 47 of the GDPR:

”The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller. Such legitimate interest could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client or in the service of the controller. At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing. Given that it is for the legislator to provide by law for the legal basis for public authorities to process personal data, that legal basis should not apply to the processing by public authorities in the performance of their tasks. The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.”

Note the explicit mentioning of “The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned”


This is a really interesting example for comparison. I think I could come up with a clear explanation of which data is kept, and for what purposes. A compliant user can have all of their data deleted upon request, with reasonable "are you sure" prompts. An abusive user will have evidence for abuse retained, and enough information to prevent spamming accounts.


Also any kind of invoice data is by law (in Denmark) required to be kept for 5 full years after closing of the books. That also means you are not allowed to delete that data in that period due to the GDPR (as the accounting law overrules the other)


What if a user you want to ban is not fraudulent, but a nuisance?


That is not as clear cut, but if you have stated your thoughts and decisions you should be in the clear.

The worst that would happen would be a letter from your DPA asking you to rectify sitation (and giving you more specific guidelines)...


If you are a billable service you don't have to worry about it that much. GDPR does not overwrite current EU or member state laws and you are compelled to keep financial transactions and related information usually for at least 5-7 years.

If it's a free service then just pseudoanonymize any identifiable information such as first and last name, email address, phone number, IP address etc. pretty much anything that you would use to identify the user with.

A hash of these values or an HMAC would be sufficient to comply with GDPR and allow you to keep them banned.

You can also check your local legislation and see if you have any laws that would support you keeping PII under the justification of protecting other individuals.


IANAL, TINLA.

From my superficial understanding of this law, you may weigh different interests and make a judgement call as to what data to delete and what to keep. Other regulations may be a factor in this, but even lacking those, it could be argued that your community cannot function otherwise. You would need to document how you came to your decision and inform the requestor about it. Note that you must still try your best. For example, you may not need to keep their actual email address to keep blocking it; a salted hash should do.


I think storing a salted hash of their email address is a reasonable measure that should satisfy GDPR ...


Maybe a stupid question, but once your list grows large, how would you then check if a new address is in your salted hashed list without iterating over every item? Unless I’m mistaken, you can’t index salted hashed lists unless the salt is predictable (which defeats the purpose of a salt).


It does not entirely beat the purpose of a salt, because still the existence of a rainbow table for that particular combination of algorithm and salt is a lot less likely than for the algorithm unsalted.

As for your question, a solution could be to allow the account at first and perform regular checks in the background. It won't make a big difference if the account is never created or deleted within 10 minutes. In fact, the latter could be better, because it will be harder to check for any outsider (including the offender) whether an address is blocked, which is good for privacy and helps keep the offender busy, because they can't use a different address right way—they first spend some time in vain.


But you can index the hashes.

Hash the email first, then check if the hash exists.


To check for matches against that index, you'd still need to hash the email you're checking for with every distinct salt in your database, separately.


Good point, if each email is individually salted as best practice for storing passwords they could not be indexed.

However, this would also mean that logging in using an email/username would also require a full scan.

More generally, if you want to uniquely salt your keys, you’re in trouble.


> However, this would also mean that logging in using an email/username would also require a full scan

No it wouldn’t, and that’s what makes this specific case different. In your scenario, you can lookup the column you need by username or email, which is indexed. You can then retrieve the unique salt and password hash with no lookup penalty. This is not possible in the other case because there is no known column that can serve as the index.


To find email for a given hash should be rather easy. Not sure how that satisfies GDPR.


Even unsalted hash would be sufficient.


no, you don't have to. math problems are not considered "personal information". their email address on the other hand it is. So the "trick" is to just delete the address and change their username to a random word ex. Guest323


Interesting question. Have you considered opening an issue on the Discourse software for help? https://github.com/discourse/discourse




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: