Fediverse

28481 readers

873 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to [email protected]!

Rules

Posts must be on topic.
Be respectful of others.
Cite the sources used for graphs and other statistics.
Follow the general Lemmy.world rules.

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 2 years ago

MODERATORS

[email protected]

[Question for admins] How do you feel about your users requesting content or account removal from other servers. (thelemmy.club)

submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

17 comments fedilink hide all child comments

I'm looking for answers from instance admins, if you're a regular user, you can still answer but it's more helpful for me to get answers directly from admins.

If a user on [instance A] asked another instance (Instance B) to remove their federated account and federated content copies from instance B (likely also banning it so content doesn't continue to flow) would the user on Instance A be in trouble with their instance admin for asking for such a thing.

Obviously it depends on the instance's rules but that's part of why I'm asking the question, to get answers from instance admins on this.

On one hand I can see how it would since, since it hurts interoperability and can create tension between instances, but on the other hand a user has the right to be in specific places or not be in those places, that probably extends to not wanting to be federated into an instance they find objectionable (assuming it is for good reasons).

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 month ago* (last edited 1 month ago) (1 children)

No, as only the instance admin that hosts the original account can indirectly associate a user handle with actual "personal data". An admin of a federated instance can not, as they do not have any "personal data" to correlate it with.

If a user themselves posts "personal data" publicly it is not covered by the GDPR (IANAL) and thus not subject to mandatory deletion requests. Of course deleting everything is often the easiest course of action, but this is not legally required.

[–] [email protected] 3 points 1 month ago (1 children)

Also not a lawyer but I've done a lot of GDPR training since it was introduced and I believe you're incorrect—the data subject posting it publicly or not doesn't factor into the validity of a deletion request under the GDPR. There are a limited set of specific reasons a service owner can refuse a deletion request and they're pretty much down to preventing abuse and facilitating compliance with other laws.

[–] [email protected] 1 points 1 month ago

Not a lawyer, but honestly, both of these takes are probably not correct.

I'd say that most fedi-services fall more into the 'can I make someone delete an email' GDPR category (tldr: probably not, but maybe) with a dose of the 'this service is for personal/non-commercial use and includes messaging and social media' exemption.

This of course won't work if you're taking money or doing commercial activity but at that point you're a business and should consult your lawyers to ensure your compliance. (And if you can't, then maybe don't be in that business.)

I wouldn't want to be the one to spend the billion dollars to litigate that, but frankly if you're not in the EU, and not a business, then the person demanding removal would have to take you to court to force compliance (assuming you didn't just do it so you don't have to deal with a grumpy person) which is... unlikely.

The much more horrifying interpretation is that the data controller, processor, and sub-processor language comes into effect and everyone needs to sign written agreements with every other fediserver to be even remotely in compliance.