Ah, okay. I haven’t really messed with Jerboa for a good while since it still seems to have issues with AOSP keyboard (last I checked in on that bug, anyway).

I was thinking of implementing a non-standard way of doing it in Tesseract (basically it would lookup the user’s instance admins and send a DM). Perhaps that’s what Jerboa is doing?

Shame, I was hoping there was an API feature for that now.

Huh. I’ll have to check that out. Unless it’s new in 0.19.4 or 5,I wasn’t aware the API would let you report users (just their content).

Thanks for the follow up.

Yep, seems manual or at least only partially automated based on feedback from other admins.

Also yeah, unfortunately, Lemmy doesn’t have the ability to report users to their home admins, just content they post. Not sure if that’s a moderation feature that’s in the pipeline or not (haven’t checked for a bit).

That would definitely work for rooting out ones local to an instance, but not cross-instance. For example, none of these were local to my instance, so I don’t have email or IP data for those and had to identify them based on activity patterns.

I worked with another instance admin who did have one of these on their instance, and they confirmed IP and email provider overlap of those accounts as well as a local alt of an active user on another instance. Unfortunately, there is no way to prove that the alt on that instance actually belongs to the “main” alt on another instance. Due to privacy policy conflicts, they couldn’t share the actual IP/email values but could confirm that there was overlap among the suspect accounts.

Admins could share IP and email info and compare, but each instance has its own privacy policy which may or may not allow for that (even for moderation purposes). I’m throwing some ideas around with other admins to find a way to share that info that doesn’t violate the privacy of any instances’ users. My current thought was to share a hash of the IP address, IP subnet, email address, and email provider. That way those hashes could be compared without revealing the actual values. The only hiccup with that is that it would be incredibly easy to generate a rainbow table of all IPv4 addresses to de-anonymize the IP hashes, so I’m back to square one lol.

Lol, that sounds like a Randall Munroe unit of measurement, and I love it. If there’s not already an xkcd for that, there should be.

Some instances do, but I think it’s more of an automod configuration. AFAIK, Lemmy doesn’t have that capability out of the box. Not sure about other fed platforms.

I used to think so, but it’s barely even that.

I’ve had 3 instance admins confirm anonymously that these were using a throwaway email service. sharklasers.com specifically.

Possibly. I don’t think I’ve been in or active in it for a while. With check it out.

Yep. Also, aren’t there already celebrities on Mastodon? I know George Takei is. Granted, you’d have to know he was @mastodon.social versus mstdn.social so that could complicate things for those unfamiliar with the platform.

OP’s definitely got a point, though.

I hope this post doesn’t tank the monthly active users stats lol. Mostly that’s me hoping this problem isn’t as big as I fear.

True. But it uses a threshold ratio. They’d have to give out a proportional number of upvotes to “fool” it, and at that point, they’re an average Lemmy user lol. That script isn’t (currently) setup to detect targeted vote brigading, just ones that are only here to downvote stuff. I’ve got other scripts to detect that, but they just generate daily/weekly reports.

It takes time to detect them, but it does prevent most false positives that way (better to err on the side of caution and all that).

yeah, i’m split on public votes.

On one hand, yeah, there’s a certain type of troll that would be easy to detect. It would also put more eyes on the problem I’m describing here.

On the other, you’d have people doing retaliatory downvotes for no reason other than revenge. That, or reporting everyone who downvoted them.

It depends on the person to use that “power” responsibly, and there are clearly people out there who would not wield it responsibly lol.

Yeah, this definitely seems more like script kiddie than adversarial nation-state. We’re not big enough here, yet anyway, that I think we’d be attracting that kind of attention and effort. However, it is a good practice run for identifying this kind of thing.

Good to know. I’m going to have to account for that in Tesseract.

Try to summarize this as briefly as I can:

I was replying to a comment in a big news community about 5 months ago. It took me probably 2 minutes, at most, to compose my reply. By the time I submitted the comment (which triggered the vote counts to update in the app), the comment I was replying to had received ~17 downvotes. This wasn’t a controversial comment or post, mind you.

17 votes in under 2 minutes on a comment is a bit unusual, so I pulled up the vote viewer to see who all had downvoted it so quickly. Most of them were these random 8 character usernames like are shown in the post.

From there, I went to the DB to look at the timestamps on those votes, and they were all rapid-fire, back to back. (e.g. someone put the comment AP ID into a script and sent their bot swarm after it)

So that’s when I realized something fishy was happening and dug deeper. Looking at what was upvoted from those, however, revealed more than what they were downvoting. Have been keeping an eye out for those type of accounts since. They stopped registering for a while, but then they started coming up again within the last week or two.

I wonder if private voting will make it too difficult to discover

Depends how it’s implemented. If the random usernames that are supplied from the private votes are random for each vote, that would make it nearly impossible to catch (and would also clutter the person table on instances with junk, one-off entries). If the private voting accounts are static and always show up with the same identifier, I don’t think it would make it much more difficult than it is now with these random user accounts being used. The kicker would be that only the private version of the account would be actionable.

The only platform with private voting I know of right now is Piefed, and I’m not sure if the private voting usernames are random each time or static (I think they’re static and just not associated with your main profile). All that said, I’m not super clear on how private voting is implemented.

Ethically, I can’t (and won’t). I’m only comfortable and confident enough to share the list of sockpuppet accounts I’ve confirmed and provide the information necessary to detect them. I did list the topics I’m aware of (US news and politics), but I’m only able to see activity based on what my instance knows about. So they may be manipulating other communities, but if my instance doesn’t subscribe to them (or they’re by posters that have been banned), I have no way of seeing it.

That’s actually why I posted this. My visibility is limited, so once I identified the pattern, I’m passing that along to other admins for awareness.

True.

I guess my main hangup with payment-based registration is trust. Personally, even though I am willing to pay for a Lemmy account (I guess I technically do since I run an instance), I would be between hesitant and completely avoidant to giving payment info to a random instance that could be hosted by anyone.

If they use some kind of well-known, trusted donation/payment service, I guess that could alleviate that. Now that I think about it, it may also encourage people to use instances more local to them since they would probably want to recognize the donation platform the instance uses. (e.g. if an instance used a donation/payment service that’s only well-known in Sweden, I would have absolutely no idea as an American if it was legit or not, would not risk it, and would choose a different instance).

I’m still not completely for the idea of requiring payment for sign up, but I definitely can see the benefits to it.

What stops the botters from setting up their own instances to create unlimited users for manipulating votes?

Nothing, really. Though bad instances like that would be quickly defederated from most. But yeah, admins would have to keep an eye on things to determine that and take action.

It’s not a native feature, but some instances have a script or plugin (not super familiar with it beyond a general awareness of its existence) that can tie their federation allow/block lists with Fediseer. So, like, if an instance gets censured by a bunch of other instances you’re on good terms with, it can automatically pick that up and add it to your block list.

I don’t hate the idea of that, and I have seen it protect a few instances from several spam waves, but I haven’t implemented it myself.

I have a manual process for admitting people, do I need to do anything if I know exactly who is on my instance,

With that in place, I wouldn’t think so. I’m in the same boat with a small instance that has always used applications. The problematic accounts I’ve noticed are all using these random, 8-character names and seem to be setting up shop across open instances w/o applications. So chances are, if you’re manually admitting people, you’d have noticed these already and likely not approved them.

do I need to do anything to protect my instance from other bad acting instances

Unfortunately, defederating only protects your instance’s users from being impacted by the manipulations. Beyond that, it’s less a bad instance rather than them being taken advantage of (kind of like our persistent troll who instance hops every few days).

For now, I’ve just banned the vote manipulation accounts and moved on (this PSA notwithstanding lol) I wouldn’t consider these a “defederation worthy” offense. When I do defed, it’s for bigger reasons or just temporary due to spam (sometimes admins can’t deal with it right away but it’s causing a huge problem now and I need to do something in the short term).

Queries, I do have some, but they’re ugly AF. lol. I should prob look into starting a Matrix room or admin community where we can share and improve each others’ utility scripts.