this post was submitted on 20 Jun 2023
24 points (92.9% liked)

Asklemmy

43989 readers
1567 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy 🔍

If your post meets the following criteria, it's welcome here!

  1. Open-ended question
  2. Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
  3. Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
  4. Not ad nauseam inducing: please make sure it is a question that would be new to most members
  5. An actual topic of discussion

Looking for support?

Looking for a community?

~Icon~ ~by~ ~@Double_[email protected]~

founded 5 years ago
MODERATORS
 

Just a random thought experiment. Let's say I have my account on a lemmy instance: [email protected]. One day I decide to stop paying for the domain and move to [email protected], and someone else gains it and also starts up a lemmy instance.

If they make their own [email protected], how do federated instances distinguish who's who?

Have I misunderstood the role of domain names in this?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (1 children)

You have instance

Let's stop it here. Instances are completely irrelevant in my idea.

but different instances as the keys don’t match

*sigh* The keys are in the Actor objects and in the Action objects and not in the instance. You cannot validate any instance, you cannot validate if an action was performed on a specific instance. You cannot prevent actors of the same name after the previous instance was wiped.

All you can do is validating if an action was performed by an actor existing at the time the action was perfoed and that both were signed with a specific key.

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

So the only things you secure are access to existing posts, comments and roles, but without any further checks if this is still the same user, correct?

So if [email protected] creates 10 posts, 100 comments and is the moderator of 5 communities (on other instances) then the public key would secure that only that user can interact with that data. Makes sense.

But now the domain gets stolen, a new Lemmy instance is set up, a new [email protected] is set up. This user is named [email protected], exactly the same as the original one. They just don't have the right key to interact with their old content.

Now that user wants to moderate one of those communities again, are they treated like a different user (because keys don't match)? Or just locked out (because you can't have two users with the same name as moderator for the community)? Your whole idea makes sense, but when it comes to enforcing those ideas you run into a dozen issues both for federation and when it comes to present the data in the UI.

And you get phishing issues on top. If they are treated as separate users by other instances, they could just write another legitimate moderator "Hey, it's me, [email protected]. I got accidentally kicked out of the community, can you re-invite me as moderator please?" so all the work you put in for security is for naught.

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

So the only things you secure are access to existing posts,

The only thing I secure is that for a given Action by a given Actor it can be validated that those were signed with a given key.

So if [email protected] creates 10 posts, 100 comments and is the moderator of 5 communities (on other instances) then the public key would secure that only that user can interact with that data.

Everyone can interact with that data, but since those are signed with a specific key the sign would become invalidated.

Now that user wants to moderate one of those communities again, are they treated like a different user (because keys don’t match)?

Since the key and signature are just additional attributes of the Actor object they'll be the same user federation-wise. An instance admin needs to manually validate why the Actor uses a different key now. If the Actor is used to perform malicious things it can be verified that those things are done with a different key. What's done with this information is up to the instance admins.

If they are treated as separate users by other instances, they could just write another legitimate moderator

Exactly. Key signing does not prevent social engineering.