We (diem25.org) are in the process of GDPR-proofing our operations. As others pointed out, the danger is not the authorities but the Abmahnanwälte, who are suing e.g. small personal blogs for lacking the legally-mandated two distinct ways of contacting the author, using images without licensing information and similar things, and who are collecting several hundred or several thousand Euros each time in settlement fees from these tiny one-person businesses. They will make a killing under the GDPR.
Here’s our understanding of what our Discourse instance should provide in order to be safe from such litigation. Can a team member please indicate which of these already exists or is in the works, so that we don’t invest time re-inventing the wheel or parallel-coding something that is already in the works?
-
Delete all - since social media posts have been ruled to be ‘personal data’, forum posts are likely to be interpreted to be the same, and fines are likely until someone goes to court over this. I heard that some forums wish to try their luck with a CC licensing of posts and anonymising only. This is not an option for us because in Germany, ownership can never be legally transferred, so the way the CC licensing works out is that you always retain the right to delete your own posts, without however gaining the right to force people who copied/quoted your posts to delete the quote. So the option to mass-delete one’s posts must exist. We wish to offer users the choice to either anonymise or truly delete their posts upon leaving our community and we hope that most will decide to anonymise. Ideally, deletion should have a safety hatch, e.g. being required to type ‘DELETE’ as in Mailchimp, or posts being marked as for-deletion in the database but only effectively being removed after one week without remorse.
-
Export all - JSON export of all rows of all tables that include the user’s ID. This seems simple to do, see e.g. https://github.com/ziptofaf/gdpr-rails . The legal purpose is twofold: a) to show the user what information is collected on them and b) allow them to import the data elsewhere, i.e. truly make them the owner of their data.
-
Auditable data processing - Companies are required to be able to provide, if requested, a log of their staff’s data processing actions. This may be covered by Discourse’s Moderator Log. However, does it cover everything? E.g. if an admin changes someone’s forum name for them, is that logged somewhere? It should be, at least internally, in order to be able to comply.
-
Consent management - We have taken note that companies now cannot sign people up to all their newsletters through their Terms and Conditions but have to get separate consent for each newsletter, detailing its purpose. Hence Discourse would be legally on much safer ground if, beyond the consent to the Terms and Conditions, the Send Me Forum Emails checkbox could be present already on the registration page.
-
Log deleted users - The GDPR states that users’ personal data must be deleted even from backups. As that is very difficult to do, short of the cryptographic solution that https://github.com/ziptofaf/gdpr-rails found, we shall simply keep no backups beyond the 30 days that we have to delete users. However, if someone deleted their account 2 days ago and we are forced to restore a backup from 3 days ago, that person’s data will be back in our system and won’t be getting removed within 30 days. Hence, the list of user IDs of deleted accounts should be stored somewhere (outside the database) in order to make it possible to delete them again while restoring a backup.
-
Removing personal data from logs, since logs are another form of storage. Should be as easy as adjusting the filter_parameter_logging.rb: https://github.com/ziptofaf/gdpr-rails/blob/master/config/initializers/filter_parameter_logging.rb
I have read some of the GDPR discussions about what is or isn’t necessary, what Discourse should or shouldn’t do, and I don’t want this post to become another one of those. Our lawyer’s interpretation of the law is this, so my only question is in how far Discourse does the listed things, or will do these things, and in how far we’ll have to code it on our own, through API or possibly a plugin for those organisations whose lawyers have the same understanding of what should be done.