I’d be really keen to host a lemmy instance but just wondering with GDPR and everything, if there is anything else to consider outside of the technical setup and provisioning of hardware?
Lemmy is storing users data so is there any requirement to do anything GDPR wise?
Hope this is the right place for this - But seen a lot of posts interested in hosting their own lemmy instance, and this is an extension of that
I am not a lawyer and definitely not anyone’s lawyer providing legal advices, but I’ve done a little bit of work around implementing GDPR compliance at my jobby job. My understanding is that you must inform users when you’re sending their data out to third party processors, and they, too, must be GDPR complaint.
So if your instance is sending information that is covered under GDPR out to other instances, you much call out those instances as data processors, and ensure they’re complaint before you add them. When you add one, I think you’re also supposed to inform users that you’re adding a new data processor via some form of notice addressed to them. Furthermore, at time of deletion, you’d also need to inform your data processors of the request, such that their compliance workflow can be followed.
In my mind, strictly speaking, what Lemmy is doing could work if the “cluster” of GDPR compliant instances doesn’t federate out to the broader non-GDPR compliant instances. So, lots of manual maintaining the allowed federation instances, each time you add a new instance, you’d then need to inform your users… once you receive a deletion request, you’d need to use the ban with purge option to purge everything on your instance, and pass that on to all federated instances. The key distinction here is ensuring your federated instances honours your purge request, which is hard to verify.
The end result is that you’d essentially be creating your own bubble of the fediverse isolated from the rest of the fediverse… which is not an ideal outcome but that’s what happens when you let regulators decide what to do on things they don’t understand…
Most of your points seem to be spot on from what I understand as well. However, I believe that the GDPR requirements can and should be baked into Lemmy itself. This would prevent the fragmentation you mentioned. A guarantee of removing user data as requested while federated plus a guarantee to remove stale user data while defederated since requests won’t get through in that case. That would “just” leave the list of processors. This one can be very tricky because you are not just sharing data with your home instance and their federated instances but also with the federated instances of those federated instances. The home instance has no way of learning about the 2nd degree federation. I have no idea how to get the network of data sharing GDPR compliant and I think this is the mich more complicated part that your proposal also suffers from.
My understanding is that the onus to have the data removed is on the originating instance owner, so they’re required to ensure their data processors (i.e.: destination federation servers) to comply. As such, while Lemmy could make it such that itself attempts to be GDPR compliant (and to some extent, with the ability to request to purge makes it relatively close), the problem is that the recipients doesn’t have to adhere to it – they could run a third party Lemmy server that ignores it. This is why you’d end up with a cluster/bubble – in order for each instance to join, they also must adhere to the standard proposed by GDPR (ensuring every single instance they federate to adhere to it, etc. etc. etc.). This becomes increasingly complicated because as more servers gets added, everyone must verify each other and comply, stunting the growth significantly… I don’t think there’s a good way around it, and thus the closing remark… complex matters are, surprisingly, complex :(