cinnyapp
Spam Invite Prevention Switch
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
using https://github.com/matrix-org/matrix-spec-proposals/pull/2666 and a bad-word filter can be considered to filter spam invites.
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 #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.
