Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spam Invite Prevention Switch #1845

Open
williamkray opened this issue Jul 26, 2024 · 3 comments
Open

Spam Invite Prevention Switch #1845

williamkray opened this issue Jul 26, 2024 · 3 comments

Comments

@williamkray
Copy link

Describe the problem

A common SPAM attack is to leverage hundreds of malicious accounts with offensive account IDs to send invites to a user, often to a room with similarly offensive name, public address, etc. In this way virtually all aspects of the invitation itself represent malicious and harmful content (mxid, room name, room aliases, etc).

Describe the solution you'd like

I and others would like a client-side feature switch to silently reject all invitations, unless the inviting account is already a member of a room that my account is in. When this feature is enabled, an invite from an unrecognized mxid should not show any notification in the client, and be automatically rejected by the server. If the mxid belongs to any room that my client is already in, it behaves normally, so someone in any other public or private room, space, or DM with me can send me additional invites.

While this would not eliminate the issue entirely, it would drastically reduce the impact due to the fact that generally, offensive account IDs are often blocked from public/shared rooms immediately, meaning that the perpetrators have to join these rooms with an unassuming mxid, and then scrape membership of the rooms and pass it to a botnet of other accounts. This feature would render that attack vector irrelevant.

Alternatives considered

Any alternatives considered generally still leave the MXID of the attacker visible, which does not address the attack vector. Protocol and server-side implementations may be feasible, but are much slower to put in place and turn into an eternal discussion, while the people being harmed by these attacks continue to be harassed.

Additional context

No response

@ajbura
Copy link
Member

ajbura commented Jul 26, 2024

using matrix-org/matrix-spec-proposals#2666 and a bad-word filter can be considered to filter spam invites.

@AdaMacey
Copy link

using matrix-org/matrix-spec-proposals#2666 and a bad-word filter can be considered to filter spam invites.

As long as a custom filter can be used specifically for invite requests. With transgender communities for example, many of the offensive words used in the invite attack vector still need to be visible in regular conversation to allow for discussion of transphobia itself

@olivia-fl
Copy link

A thing I've experienced a few times is abuse users joining a large matrix.org-moderated room (usually #matrix-dev or #foundation-office), spam-pinging a bunch of people, sending a bunch of abuse media, and then sending invites to people in the room with abuse content in the name and room avatar. This feature doesn't help with this situation much because m.org moderation is not very active and it often takes a long time for them to be banned.

My main direct problem with this type of spam invite is that it seeds my HS's cache with abuse media that I then have to delete. A thing that would be very helpful here is the ability to hide room and user avatars by default, similar to how you can hide media in messages by default. Textual abuse content in userids, roomids, and displaynames is a problem, but a much less severe one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants