3386
submitted 1 year ago* (last edited 1 year ago) by muddybulldog@mylemmy.win to c/youshouldknow@lemmy.world

Edit: obligatory explanation (thanks mods for squaring me away)...

What you see via the UI isn't "all that exists". Unlike Reddit, where everything is a black box, there are a lot more eyeballs who can see "under the hood". Any instance admin, proper or rogue, gets a ton of information that users won't normally see. The attached example demonstrates that while users will only see upvote/downvote tallies, admins can see who actually performed those actions.

Edit: To clarify, not just YOUR instance admin gets this info. This is ANY instance admin across the Fediverse.

you are viewing a single comment's thread
view the rest of the comments
[-] dukk@programming.dev 54 points 1 year ago

Couldn’t we just use a hash for the usernames instead?

Nothing too over the top, but just a simple hash and match that instead?

Also, there’s way too much trust in instances. Like, one person could easily make a post on lemmy.world, go on their personal instance, and just give themselves, say, 2000 upvotes.

Instances should have their own settings on what instances are allowed to keep a local copy. (Default behavior should be to get the post itself from the instance “hosting” it).

[-] chris@l.roofo.cc 17 points 1 year ago

If that is a solution you'd need to change the ActivityPub specification. You are more than welcome to submit your idea.

Also, there’s way too much trust in instances. Like, one person could easily make a post on lemmy.world, go on their personal instance, and just give themselves, say, 2000 upvotes.

I'd first have to create 2000 users, then I'd have to send 2000 upvotes. And then I'd get blocked by all instances.

Instances should have their own settings on what instances are allowed to keep a local copy.

This is also not compatible with the ActivityPub spec but even if it were you'd win nothing because as soon as you fetch the post it is still on the server.

[-] lalo@discuss.tchncs.de 7 points 1 year ago

Hey, just curious: how would all the instances discover this type of fraud?

[-] dukk@programming.dev 5 points 1 year ago

They'd have to check the upvotes, notice most of them came from one instance, look at the instance, check multiple users, and if they realize that these users were just created to get upvotes then they can defederate. However, it's too big of an assumption that moderators will go through that kind of effort to validate all the upvotes.

[-] dukk@programming.dev 2 points 1 year ago

If that is a solution you’d need to change the ActivityPub specification. You are more than welcome to submit your idea.

AFAIK, the ActivityPub specification has no requirements on how likes should be stored. The two things that is requires are that likes are added to the user's liked collection, and that the post's like count is updated.

This is also not compatible with the ActivityPub spec but even if it were you’d win nothing because as soon as you fetch the post it is still on the server.

Mastodon actually just stores all this data on the server containing the post itself. Instance admins get as much information about the post as the client does. Both Lemmy and Mastodon use the same protocol, but Mastodon chooses to only to trust the server the user is using, and not the third-party servers.

I’d first have to create 2000 users, then I’d have to send 2000 upvotes. And then I’d get blocked by all instances.

Creating that many users wouldn't be hard to do(you don't need to use the GUI, just a little SQL is all that's needed). And you don't need to "send" the upvotes; you can sidestep the protocol entirely and just update the database. That's the problem.

And while yeah, the instances would block me, they probably wouldn't notice if I did it at a much smaller scale. In fact, there's no real easy way to check whether these upvotes from an instance are actually real.

[-] grimsolem@lemmy.dbzer0.com 5 points 1 year ago* (last edited 1 year ago)

Couldn’t we just use a hash for the usernames instead?

The hash function would still need to be public to share data between instances.

[-] dukk@programming.dev 4 points 1 year ago* (last edited 1 year ago)

That's the point of a hash function. You have a public hash function, say SHA-256. It's easy to check a username against it's hash, but virtually impossible to reverse the hash back to the username.

Edit: Instead of storing, say, eddie, we'd store 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d. Then when the instance gets a Like from eddie, it hashes his username to get 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, realizes there's a match, and doesn't update the count.

Note that when given 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, it would take millions of CPU years to compute the original username from it. Therefore, we can check for duplicates without actually checking the name itself (a similar method is used for checking passwords; Lemmy is open source, we know the hashing algorithm, but we can't unhash user passwords, only check them).

[-] quintium@lemmy.world 2 points 1 year ago* (last edited 1 year ago)

While there is an enormous amount of possible passwords, there is only a limited (and quite small) amount of users. Couldn't you just hash all the usernames one by one and map the hashes to the usernames? So you could still reverse engineer the usernames of those who voted on a post.

Edit: Salting with the post id would make this attacking process harder, but still realistic. Probably the only real solution is to hide the votes table from federated instances, I'm not sure if that brings technical problems.

[-] sab@lemmy.world 1 points 1 year ago

If anything, wouldn't that make vote abuse even easier? Just send 100 upvotes with 100 random hashes.

[-] dukk@programming.dev 1 points 1 year ago

That was what I was implying, yes.

Just hash each username and store it. Then just check the usernames hash to see if it matches.

[-] quintium@lemmy.world 1 points 1 year ago

I was more comnenting that you could still reverse engineer the users who voted on a post

[-] dukk@programming.dev 1 points 1 year ago

Actually, you’re not really wrong.

All the more reason to give out limited data to all other instances. Why do these instances really need this data? Mastodon doesn’t need it, not quite sure why Lemmy does it.

[-] quintium@lemmy.world 2 points 1 year ago

Yeah I don't understand why every instance can't keep track of their own votes privately. Sure, voting manipulation is a thing, but it's possible regardless.

Honestly I really hope Lemmy does something to address this issue. Otherwise it's kind of a dealbreaker for me.

[-] sab@lemmy.world 4 points 1 year ago* (last edited 1 year ago)

Also, there’s way too much trust in instances.

I say there's too much care about votes. Because someone can just give themselves infinite votes from their private instance, it makes it all the more worthless.

Instances should have their own settings on what instances are allowed to keep a local copy.

There's a setting for that, it's called the allowed list - configures who are allowed to federate with you. Beyond that - if it's out, it's out.

[-] dukk@programming.dev 2 points 1 year ago

Votes are the only real way currently to gauge opinion about the post itself. IMO, if the votes system is so bad that people are starting to completely disregard it, there’s something wrong.

[-] Serinus@lemmy.ml 1 points 1 year ago

It's a lot easier to fake a hash than a username. If I'm an instance owner and I suspect another instance of this, I can grab a random username and check their post history. Pretty easy to see rampant fraud that way.

If you're putting something out on the internet, even upvotes or clicks, expect it to be public.

this post was submitted on 04 Jul 2023
3386 points (96.1% liked)

You Should Know

33379 readers
24 users here now

YSK - for all the things that can make your life easier!

The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:

Rules (interactive)


Rule 1- All posts must begin with YSK.

All posts must begin with YSK. If you're a Mastodon user, then include YSK after @youshouldknow. This is a community to share tips and tricks that will help you improve your life.



Rule 2- Your post body text must include the reason "Why" YSK:

**In your post's text body, you must include the reason "Why" YSK: It’s helpful for readability, and informs readers about the importance of the content. **



Rule 3- Do not seek mental, medical and professional help here.

Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.



Rule 4- No self promotion or upvote-farming of any kind.

That's it.



Rule 5- No baiting or sealioning or promoting an agenda.

Posts and comments which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.



Rule 6- Regarding non-YSK posts.

Provided it is about the community itself, you may post non-YSK posts using the [META] tag on your post title.



Rule 7- You can't harass or disturb other members.

If you harass or discriminate against any individual member, you will be removed.

If you are a member, sympathizer or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people and you were provably vocal about your hate, then you will be banned on sight.

For further explanation, clarification and feedback about this rule, you may follow this link.



Rule 8- All comments should try to stay relevant to their parent content.



Rule 9- Reposts from other platforms are not allowed.

Let everyone have their own content.



Rule 10- The majority of bots aren't allowed to participate here.

Unless included in our Whitelist for Bots, your bot will not be allowed to participate in this community. To have your bot whitelisted, please contact the moderators for a short review.



Partnered Communities:

You can view our partnered communities list by following this link. To partner with our community and be included, you are free to message the moderators or comment on a pinned post.

Community Moderation

For inquiry on becoming a moderator of this community, you may comment on the pinned post of the time, or simply shoot a message to the current moderators.

Credits

Our icon(masterpiece) was made by @clen15!

founded 2 years ago
MODERATORS