this post was submitted on 19 Jun 2023
157 points (100.0% liked)
Technology
37748 readers
178 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.