this post was submitted on 19 Aug 2024
688 points (97.5% liked)
Fediverse
28499 readers
339 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 !moderators@lemmy.world!
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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Agreed. 10/10.
And you don't even need real crypto here to start. The home instance can just send vote actions as fixed unique tokens. The way the trust framework currently works, this is literally a drop-in replacement and introduces no new spam/brigade vulns which don't already exist from a rogue instance. It would be imperfect, and may still make it possible to correlate and infer vote patterns for a sufficiently motivated adve, but it would raise the bar for protecting user telemetry by a huge factor with very minimal effort. I'm honestly a bit surprised it hasn't been done already.
It does though. Now a rogue instance would have to have "believable" profiles for the accounts that vote, because an instance of just "lurkers" who seem to suspiciously vote is a pretty big signal of vote manipulation. If you only see a random identifier (or not even that, just a tally of votes) it'd be impossible to tell if it's truly the instance's users just passionate about something or actual vote manipulation.
In other words it would at least make the problem way worse.
The rogue instance would still need fake users though. It would be very easy to see if you are getting votes from 300 unique tokens, but the instance only has 100 users.
Also the method I am proposing would simply be transparent in terms of user management, so if you are running core Lemmy, the only way to generate voting tokens would be to generate users.
I guess that's true. Then you could just ask the instance admins to check their users' voting patterns / deanonymize them / whatever, and if they don't comply defederate them.