Support Honey Pots to catch spammers

[Tyler-IN]

We need a read-DMs-only can't-even-read-channels no-bot-tag-indistinguishable-from-an-ordinary-user extra-verification-required API for creating honey pot bots to catch spammers quickly and efficiently.

Need an amount of these kinds of bots proportional to the number of users in a discord server; they need to not count toward the true pop-count of the server, they need to be distinguishable (and maybe by default hidden) from real users by users with some non-default-role flag.

They need to not receive any events other than DMs.

Can we make this happen? Forget I asked. Thanks for the non-constructive dismissal. Spammers downvote.

[Tyler-IN]

Ok, judging by the dismissal this has received, I guess we prefer to fight spam on Discord with tweezers instead of empowering community efforts. 👎

[Lachee]

You fight spam by disabling DMs and reporting bot accounts to discord. There are far better alternatives that can be done to the API itself than to allow "bots that are user bots but not actually".

[muddyfish]

Honey potting would be a pretty good idea except there are perfectly good reasons to DM/interact with an inactive user

[Skillz4Killz]

Wouldn't a better and easier solution just be a new permission server-wide that prevents a user from sending(non-friends) a DM.

By default keep it disabled and then bots that need to dm like welcome/mail bots can be given express permission to DM members on that server. This would also prevent user bots I imagine.

[LikeLakers2]

@Skillz4Killz That'd be annoying for legitimate users, unfortunately -- and it'd take away from the user's autonomy about how they want to control DMs sent to them.

It's honestly just easier to remind people that reporting, blocking, and privacy settings all exist -- and to remind people that those "free nitro" and "join my minecraft server for free robux" messages are scams.

[Tyler-IN]

You fight spam by disabling DMs and reporting bot accounts to discord. There are far better alternatives that can be done to the API itself than to allow "bots that are user bots but not actually".

They're not just scams, they're automated scams. Honey potting is how we effectively fight spam with emails and messaging. The individuals compromised by the scams become unsuspecting scammers themselves. Discord hurts itself by allowing this sort of thing to propagate without a legitimately effective automatic response.

Honey potting would be a pretty good idea except there are perfectly good reasons to DM/interact with an inactive user

Bayesian filtering for determining if an interaction is legitimate or spam. These sorts of problems have already been solved.

I'm arguing with a bunch of people that have already dismissed the idea completely despite it's legitimacy, track record of success, distributed and automated nature and are perfectly happy to allow this sort of nonsense to continue, so what's the point?

It's not like a security engineer would volunteer input and expect comfortable people to wake up and smell the BS.

People will keep reporting, spam will keep propagating faster than the human response, messaging filters will be worked around, etc. Hundreds of people will repeatedly and continuously fall victim at a time. Eventually you'll get competition that does a better job.

[ghost]

it's fairly simple as a spam bot author to just not DM inactive users, so your solution of creating inactive users that can only receive DMs is quite useless.

[Tyler-IN]

And I take it you don't see a simple solution for that?

[ghost]

personally im with @Skillz4Killz for this. others seem to find it too restrictive, but i can understand why some larger guilds may be ok with the tradeoff of somewhat impacting ux

maybe a guild-wide default that can be overridden by the user themselves to be able to receive dms would be better?

[advaith1]

that would be a good idea (and many people have been asking for it for a long time) but it should be enabled by default (like it is currently) and be able to be overridden by the user

[kotx]

If the client can filter them out, then the spammers can. If the client can't filter them out, then there are obviously going to be false positives.

[ghost]

Edit: I wrote a massive text before and then came to a very simple conclusion. All we need actually is to allow self-bots as per TOS that don't send any messages. The TOS currently disallow developers from self-botting - However making self bots, that don't send any messages and aren't used to inflate user numbers on servers an "allowed" thing, would allow security devs to develop countermeasures without breaking TOS.

That is the only real hurdle, we don't need a specified honeypot API function.

Security oriented developers would therefore have the tools they need + accounts that are indistinguishable from normal users, because they are normal users.

In fact the API as it is right now can easily be fooled to think a bot is a normal user. Spammers and Scammers are already doing it.

[TYoungSL]

Yeah it is that simple. You got a clique of the comfortable and clueless to convince though, and I don't know if that'll do it. Good luck.

[devsnek]

In my 4 years on this platform - No one who was harmless ever said the word "buy" in a DM, from a server I NEVER wrote a message on, a person I NEVER spoke to before. EVER. Show me anyone who did. People simply do not do this.

I don't buy it

[ghost]

In my 4 years on this platform - No one who was harmless ever said the word "buy" in a DM, from a server I NEVER wrote a message on, a person I NEVER spoke to before. EVER. Show me anyone who did. People simply do not do this.

I don't buy it

Unless you perform a moderation role or any other administrative role on a server - If you never send a single message, people don't message you "just to make friends" unless its extremely small and tightly nit communities and those simply don't need honeypots.

Disregard what I wrote though. I edited my message. I got too carried away with getting integrated functionality within the API - We don't need that, because we already have that. We actually just need Discord to rephrase their TOS to allow the safe usage of Honeypots.

Spammers are already fooling the API into thinking their users are legit, we can do the same, but in a protective manner, once it's allowed, of course.

[devsnek]

On a more serious note, we have no plans to pursue vigilante moderation. If you come across behavior which breaks our TOS, report it to us.

[ghost]

On a more serious note, we have no plans to pursue vigilante moderation. If you come across behavior which breaks our TOS, report it to us.

Trust and Safety, according to their own docs cannot perform actions against scammers who wipe their chats. Reports so far have shown no effect as soon as the scammers didn't get the result they wanted, they wiped their chats and their accounts are still actively being used to this day.

Edit: Calling banning scammers "vigilante moderation", implies that normal server administrators who try to protect their community are "vigilante moderators". I don't really agree with that statement :/

[TYoungSL]

Fighting scam spam is vigilante moderation. Got it, thanks for clarifying.

[advaith1]

Trust and Safety, according to their own docs cannot perform actions against scammers who wipe their chats

If the message is reported in-app then it is saved and t&s will be able to see it after it is deleted, for more info see https://dis.gd/dma104

[ghost]

Trust and Safety, according to their own docs cannot perform actions against scammers who wipe their chats

If the message is reported in-app then it is saved and t&s will be able to see it after it is deleted, for more info see https://dis.gd/dma104

Oh wow. This is something I haven't even be aware of for years. The first official result I get when googling is this help article (https://support.discord.com/hc/de/articles/360000291932-Einen-Fall-richtig-bei-unserem-Trust-Safety-Team-melden) hope the website properly auto-detects your language.

Confused why your option isn't mentioned in the help article, right where the big fat bold red text says "if the message is deleted we cant do anything" - That text should properly redirect to the alternative of in-app reports.

Thanks for the hint tho - Will definetly make more use of that from now on 😄

[ghost]

Trust and Safety, according to their own docs cannot perform actions against scammers who wipe their chats

If the message is reported in-app then it is saved and t&s will be able to see it after it is deleted, for more info see https://dis.gd/dma104

I just checked and that option does not show up for me at all in the app.

[advaith1]

currently it's only open to everyone on mobile (iOS and android), on desktop it's only available while deleting a message or if you're in certain programs