this post was submitted on 19 Jun 2023
152 points (100.0% liked)
Technology
37739 readers
631 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
Which is indeed a problem as it makes it impossible for any admin to host in the EU or for EU citizens, in theory. GDPR §7 makes it very clear that complete deletion of all personal data (and yes,a Lemmy comment is personal data) must be facilitated by the original data collection point.
From what I understand instance 1 has to delete data if requested, but instance 2 has no obligation to unless requested. Just like data remains archived in sites like internet archive or other private archives. Just like it works on reddit or any other site currently.
it can't make it impossible. If facebook sold data to amazon, so now amazon has a copy, and then facebook's user asks their data to be deleted, facebook can't just march into amazon's servers and delete the data themselves. The best they can do is send a formal notice to amazon requesting it be deleted, which sounds like what lemmy does. At this point it's up to the federated server if they comply with the law...
Actually that is exactly what the GDPR stipulates. In your example Facebook needs a data processing agreement that ensures that all rights of the data owners are secured and the GDPR is followed. Facebook is liable here, not Amazon - the user must explicitly NOT ask Amazon to delete as the user may not even know where the data went to/should not be bothered to write requests to a huge amount of different data processing locations.
But, @hikaru755@feddit.de added another interesting point: The Instance may or may not be seen as a single data processing entity that does not voluntarily hands over data to other instances. That could indeed be a reasonable cause as e.g. data scrubbers are not within the sphere of influence of e.g. a service publicly displaying data. But as the whole network is build on interconnected nodes I wouldn't count on it if that reasoning would fly in front of a court. It may. Or it may not.
In this case though, would it not be that then if Facebook did have a processing agreement with Amazon with which they communicate information, and this agreement stipulates that (in order to comply with GDPR) data they sell to amazon must be deleted upon request, and Amazon does NOT do so, this would make amazon liable for breach of contract instead of facebook being liable for breach of GDPR?
If so, all fediverse instances would need is a copy-paste agreement when two instances federate that data from one must be deleted on the other upon request.
Partially right - Amazon would be liable, but not towards the data owner but Facebook. The data owner sues Facebook, Facebook then sues Amazon.
A copy&paste agreement is the first (and from my point of few most important step). Personally I would also integrate a automatic mechanism that deletes data (e.g. the delete request gets automatically federated) and defederates instances that do not follow them globally. Sadly this is still not enough - data handling in the US and other jurisdictions with similar bad privacy laws is also a problem, see the recent Facebook case and Schremp2. But tbh I have no idea how to solve that.
Lemmy can, by definition, not be GDPR obtain full GDPR compliance. We should make sure that best effort is ensured, especially with the right of deletion and the right to "know"(where data is stored), but also consider lobbying towards a reformed law for the federated use cases.
The originating instance definitely cannot be held responsible for failing to force a separate instance in another country to delete its cached copy of user data imo. I think what is more likely is that EU courts could force European Jimmy instances to only federate with GDPR-compliant instances. (so federation by whitelist rather than blacklist)
This is incorrect if the data transfer was done voluntarily/planned. This also applies to EU data outside the EU - Meta has been fined a 1.2 billion euro for that.
And no, the definitive definition of the data transfer extent is a key point of the GDPR. Each and every data owner has the right to know where their data is stored exactly. So a "EU only" would not be enough - It is basically already mandatory as transfer to other countries is a major problem after Schrems 2.
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, 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 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.