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
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 :(
Yes, I agree. This use case likely wasn’t considered when the law was written. We’ll see how things turn out in the future because at some point we will have enough very knowledgeable people regarding GDPR in the community who are willing and even keen on steering the project in the right direction towards compliance.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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 :(
Yes, I agree. This use case likely wasn’t considered when the law was written. We’ll see how things turn out in the future because at some point we will have enough very knowledgeable people regarding GDPR in the community who are willing and even keen on steering the project in the right direction towards compliance.