As the Fediverse grows more and more, rules and regulations become more important. For example, is Lemmy GDPR compliant? If not, are admins aware of the possible consequence? What does this mean for the growth of Lemmy?
Edit: The question “is Lemmy GDPR compliant” should mean, does the software stack provide admins with means to be GDPR compliant.
Edit2: Similar discussion with many interesting opinions on lemmy.ml by /u/infamousbelgian@waste-of.space–> https://lemmy.ml/post/1409164
Edit3: direct link to philpo great answer–>https://feddit.de/comment/840786
Former (small scale) data protection officer here. While I am long out off the data protection game and there are surely a lot more qualified people out there I maybe can clear up a few misconceptions here and answer a few questions that come up regularly:
(BTW: My first language is not English and all my comments/books on that topic are not in English so excuse me if my translations are sometimes not 100% accurate)
- Does the GDPR even apply to a instance hosted outside the European Union?
It absolutely does. And in fact it is harder to comply to the GDPR outside of the European union. The GDPR does apply to all data collectors (from now on DCs) that collect data of European citiziens. While §2 Section 2a GDPR limits the application of the GDPR to usage within EU laws the collection of EU citiziens information clearly falls under the EU law as long as the EU citizien is within the EU during the collection process.
- So why is it harder to comply to EU law outside of the EU?
Because of local laws. A good example are US homeland security laws that do contradict the GDPR (and various other EU laws) and therefore make it impossible for someone to host EU data in the US complying to the GDPR. Facebook made a pretty costly experience in that regard recently. To comply to the GDPR one would need to keep EU citiziens out of their service AND defederate all EU instances. More of that later.
- Does the GDPR even apply to Lemmy posts?
It absolutely does! GDPR §4.1 states clearly that all information relating to an “online identifier” (aka username) is already protected. So the IP adresses, etc. collected by the initial server aren’t even the only personal data. This makes the whole topic a clusterfuck in terms of federation.
- But what about my small/medium size instance?
I am not a business! I make no money. The GDPR does not care a bit about ones intentions here - it applies to all instances that are beyond “personal or intrafamiliy” data collection. This basically means that you can absolutely do what you want with the data you collected at the last family reunion. Maybe one can even get away with a invitation only private instance that only caters to a group of friends knowing each other. But any DC having a public instance is not, by definition, a private DC anymore. Therefore the GDPR does absolutely apply.
- Can I simply the user for permission to use their data indefinitly and however I want?
One surely can ask that. But that automatically invalidates the agreement. (Funnily enough this is exactly what reddit does and why reddit is not in compliance. Which might turn out costly.) The consent always has to be revokeable, amongst other things.
- So what does the GDPR stipulate?
There are three main topic we need to look at: Data deletion, traceability of data transfers and connected to this information about data usage.
Lets start with traceability. Because that makes the federation a federation!
- What does traceability of data transfers mean?
It basically means that a DC must record its data transfers to third parties and ensure that data is handled there according to the consent agreement with the user and the GDPR. Usually a data transfer agreement is necessary to ensure the rights of all parties. This makes it so difficult for a federated system: In theory a instance would need a data transfer agreement with ALL instances that federate data from it. And these instances woud then need to make sure that they don’t transfer OR their transferpartner is covered in the original data transfer agreement as well their own one. A receipe for a pretty nice clusterfuck.
- What does data deletion mean?
Under the GDPR every user has the right to have his data deleted from a DC. This does not include data necessary for legal obligations but basically everything else. So the user can at any point revoke his consent and make the instance delete all their data.
- Okay, I deleted the data on my instance, do I now comply to the GDPR? Surely I can simply ask the user to go to the other instances and ask them to remove the data?
No. And here is another problem: The original DC (the users instance) is responsible for the data handled through transfer. That’s why one needs a transfer agreement. To ensure that the data is deleted on all instances it was transfered to. There are two exceptions here: “Involuntary data transfer” is generally seen as not being part of the data handling. But that mainly applies to datascrapers like the web archive and similar usage where the data is transfered through general usage of a page that the DC cannot reasonaby prevent without limiting the usage of their service massively. That would very very likely not apply to a service that does provide a specialised api for the transfer. The other one is a data transfer partner not complying. In that case the user can sue the DC, but the DC can sue the transfer partner for breach of contract.
- What does right to information usage mean?
Basically a user has a right to know what happened to their data. So in case of the federation: To what instances got my data transfered to? How did they use it? Did they transfer it?
- The end: What does that mean for Lemmy?
To be honest: I can not fathom a way that put Lemmy in a position that is fully GDPR compliance. There might be one, but I can’t imagine one that does not entail full defederation. But Lemmy can and must urgently improve the GDPR compliance as far as possible:
- We need tooling for administrators to easily remove a users personal information from their own instances. Currently this is still very bothersome and time consuming manual work as far as I know.
- We need a tool to federate deletion requests. So once the administrator of the “original instance” deletes the data a request is sent out to all instances and they automatically delete the user data then.
- We need a system to deal with instances who do not follow deletion requests. This, for example, could include a “karma” system - once you are caught to not delete the userdata you are getting bad karma. And with enough bad Karma you get defederated by more and more instances.
- We need a tool to inform people which instances did federate their data.
- We need to optimize data frugality: The less data is collected the better it is.
- We should consider data transfer agreements between the instances being set up automatically.
In theory even then someone can sue an instance owner. Even then we are not 100% in compliance. But it is a far better position in court if one can argue that they did basically everything they can to ensure the users right compared to “I don’t give a f****, your honour”.
Additionally we should lobby for change in the GDPR to include better rules for federated systems. Also because E-Mail as another federated system is not in compliance - that can easily be weaponized as a good point.
Edit: Just a few thoughts: Considering all this I personally would make a public instance a company or a association to limit the personal liability. Limited companies and in some EU countries associations limit the personal liability of the owner/ceo/board members massively and while they generally attract much more legal action it is easier to simply close a limited/association if one is in bankruptcy after a lost court case.
Nevertheless, it is still bad karma in court if the other side can prove that one did create a limited company,etc. just to effectively break the law, in that case even then the owner/board member is not protected and their personal assets are up for grabs.
One has to refinance the financial obligations from the limited company/association, though and of course bookkeeping,etc. becomes more burdensome. Especially the refinancing term is harder for a company as Ads do not fly on this platform and in most jurisdictions you cannot accept donations as a company. Therefore a association might be a better plattform.
Lemmy is GDPR compliant, as far as I know.
Admins can entirely purge you off their instance, should you ask them to, and other servers do not store any personal details that GDPR would require be deletable. By most interpretations.
It can be argued that previously federated data that is now out of reach and as such cannot be deleted, could constitute a breach of GDPR.
Personal data posted by the user also falls into this, so they might have to force deleting on any instance hosted by organizations. Individuals or small teams running instances which don’t take money don’t need to comply to GDPR.
GDPR Art 4.(1) ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
Posts in the Lemmy instances contain information relating to an identifiable natural person (by their user handle), as they contain the person’s ideas and opinions. Therefore the Lemmy instances are handling personal data and must comply with the GDPR.
Lemmy can avoid the impossibly heavy burden of compliance by becoming an underground illegal service and/or IP banning the Europeans Union and/or abolishing the European Union.
abolishing the European Union
Ah, yes. I believe this was step 4 of setting up your self-hosted instance.
Yes, someone please automate this