-
-
Notifications
You must be signed in to change notification settings - Fork 262
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
Comments
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 |
A thing I've experienced a few times is abuse users joining a large matrix.org-moderated room (usually 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. |
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
The text was updated successfully, but these errors were encountered: