- cross-posted to:
- foss@beehaw.org
- cross-posted to:
- foss@beehaw.org
Federated services have always had privacy issues but I expected Lemmy would have the fewest, but it’s visibly worse for privacy than even Reddit.
- Deleted comments remain on the server but hidden to non-admins, the username remains visible
- Deleted account usernames remain visible too
- Anything remains visible on federated servers!
- When you delete your account, media does not get deleted on any server
I don’t think it’s quite that bad/simple. Viewing your main instance as the Controller and other instances as Processors in GDPR terms won’t work, because instances don’t have the necessary control over each other for that, as you say.
However, you could circumvent that issue by making the case that each instance actually acts as an independent Controller. By participating on a federated service, you are explicitly agreeing to the data you provide (your profile, posts, comments, etc.) being made public and shared with other compatible services. That should be enough as the basis for other instances to reasonably assume you want your data to be processed by them, which (I think, not a lawyer) is sufficient justification for processing the data independently, as long as it’s in line with how you generally expect the fediverse to work.
This would mean that each federated instance is its own, independent entity that processes your data, and to make use of your rights under GDPR, you need to do that with each of them individually. They effectively become their own “original data collection point”, in your words, even if that data collection was not explicitly triggered by you.
The only thing missing for that to be legal (again, in my layman’s view) is transparency about who’s processing your data and how, which is necessary under GDPR. Every instance that receives your data via federation would need to let you know about that, and make available to you information on how exactly your data is processed and how you can make use of your rights under GDPR with them. That, in turn, would probably be easiest if the protocol spoken between fediverse servers were extend with automated and standardized ways to propagate GDPR requests from your home instance to any other instance that is processing your data, so that you don’t have to actually deal with every single server yourself to get your rights enacted. Defederation in the meantime might be a problem, but there’s ways around that, too.
Will write a longer post later, mobile killed my post three times by now… Anyway: doesn’t work that way, GDPR stipulates that consent must be defined and limited. “Unlimited” card blanc consent is not possible. And the initial data processing facility is still liable for the agreement.
The first point is indeed the only one I see atm that might be working. If one can reasonably argue that the node/instance is not voluntarily giving away the data and has no way to prevent that without massively hampering operation of the plattform it might be acceptable in front of a court.
Again: With a lots of might/could/ifs.
Because simply the fact that the nodes themselves are build for connecting to each other and very much do so (and you can effectively block other nodes from federating your content to a extent) speaks against that reasoning. But it worked for e.g. data scrubbers,etc.
That sadly explicitly does not work. Any consent given must be under definitive circumstances - a ‘card blanc’ consent is not possible under the GDPR. You must absolutely know where, by whom and what for your data is processed or transfered. And the initial data processor still has the obligation for a data processing agreement.