Invite spam harassment counter measures

konomikitten commented 1 month ago

Your use case

What would you like to do?

I'd like to be able to report invites. At the moment the options for invites are: "Reject" "Reject & Ignore" we need a third option of "Reject, Ignore and Report".
The option to turn off invites completely.

Why would you like to do it?

There has recently been a massive harassment campaign using invite spam. Bigots who perpetrated these attacks used invite spam to achieve it. Because invites allow them to both send their full username and host name they can put threats, abuse and slurs in them. Also avatars are sent as well enabling them to put offensive images to the person they are invite spamming.

Also because there is no report option for invites users receiving threats and abuse have to go through the tedious process of using abuse@matrix.org. A lot of users probably don't even know this exists and therefor have no one to reach out to to report this abuse.

How would you like to achieve it?

The client should be updated to allow ignoring all invite requests and have a third option of Reject, Ignore and Report for invites.

Have you considered any alternatives?

No response

Additional context

No response

emi-rose commented 1 month ago

This is very much needed, and can affect certain communities constantly... (making the "occasional" designition very inaccurate)

konomikitten commented 1 month ago

I also found the Occasional tag to unjustified, for a lot of us this happens frequently.

supakaity commented 1 month ago

A lot of the users on our matrix server have recently been complaining about invite spam and asking if they can turn off invites as a result. This would be a good feature to be able to recommend to them.

konomikitten commented 1 month ago

Unfortunately I'm still receiving harassing invites while using the matrix.org home server. At this point until The Matrix Foundation put more protections in place or even give an indication of wanting to do so anyone reading this should consider element and the matrix protocol open to abuse/spam and not worth using.

If you are targeted there is nothing you can do to protect yourself. It's not worth your time to use.

bb010g commented 1 month ago

I want to note that the Matrix specification doesn't support reporting spam invites to the homeserver, for the cases where invite spam isn't coming from an overall spam homeserver.

The Matrix specification also doesn't support ignoring invites.

This Week in Matrix 2019-08-30 brought up invite spam and quoted 3 counter-methods from @turt2live, but only method 2 there (use of synapse-simple-antispam or Mjolnir) really scales, unless you want to automate the Synapse admin API from method 1 I suppose (but that's still specific to Synapse).

Resolved issue from 2019 around Shutdown Room (which has since been replaced): https://github.com/matrix-org/synapse/issues/5575
The current moderation docs, which used to mention the delete room API (i.e. method 1), no longer document deleting a room, instead mainly documenting Mjolnir (method 2): https://matrix.org/docs/communities/moderation/
Mjolnir rejects invites in a way that's more noticable to spammers: https://github.com/matrix-org/mjolnir/issues/300

Invite metadata was known to be a spam vector as far back as 2015.

(Though this issue only mentions room metadata (name, topic) and not user metadata.): https://github.com/matrix-org/matrix-spec-proposals/issues/491
Partial spiritual successor to the previous issue: https://github.com/element-hq/synapse/issues/10311
https://github.com/element-hq/element-web/issues/11997

Other related issues I found:

turt2live commented 1 month ago

Thanks for the ping @bb010g and detailed link tree! The spec does have https://github.com/matrix-org/matrix-spec-proposals/pull/4151 now for reporting rooms to the homeserver, and matrix.org specifically monitors that report stream now too. Other (Synapse) server admins will see them appear under the room_reports table - an admin API like for event reports is planned, but not expected in the near future (sorry, lots to do on T&S generally).

Element iOS and I believe the other Element mobile clients support this API specifically for reporting rooms from the room directory, but it should be trivial to expand to other areas of the app. If T&S gets some time, we'll be contributing that change to Element Web/Desktop ourselves. In the meantime, PRs to add the feature are greatly appreciated.

The missing piece is definitely the ability to ignore rooms/invites entirely, as rejecting them can lead to further abuse. There's a few MSCs, as you've noted, with the addition of https://github.com/matrix-org/matrix-spec-proposals/pull/2270 - we're currently undecided on which direction to go, but the general approach of being able to ignore rooms is leading the process.

Another thought is to limit invites to "contacts only", assuming we can also specify what "contacts" are. This requires a lot more work to get implemented, but would help cut down on the spam at the source rather than being reactive. I also don't have a timeline for this project, but it's certainly top of mind right now.

We're a small T&S team at the moment and looking to expand once funding makes itself available. Folks can help us solve the invite issues by opening PRs for reporting rooms, contributing thoughts to the ignoring invites MSCs, and theorizing about how a contacts-only invite approach might work (and what other levels may be included in there). This is obviously quite a big ask, but we appreciate any movement folks are able to contribute towards solving these issues. We'll get to it ourselves in due course - we 'just' need to finish some of our other projects first.

joshsimmons commented 1 month ago

Thank you for opening this issue. This is a valuable discussion and the issues are very real. Since this touches on Trust & Safety in a broader sense, beyond Element's clients, I thought I should weigh in as Managing Director of the Matrix.org Foundation.

T&S is a definite sore spot right now, and that's why T&S forms the largest part of our small staff and is one of only two areas where the Foundation is actively funding development.

We are addressing T&S at the protocol level, and with tooling for homeserver admins starting with Matrix.org, and coordinating with client, server, and other developers in the Matrix ecosystem. Further, our roadmap for 2024 includes hiring another moderator and convening a ecosystem-wide Working Group on T&S to help us move further, faster, together to ensure the Matrix open federation is a pleasant place to be.

Of course, I don't expect anyone, much less people who have to cope with regular harassment, to take me at my word. Judge us on results.

Again, thank you. Keep speaking up and, where and when you can, chip in. This is definitely a communal journey!

TheArcaneBrony commented 1 month ago

At this point until The Matrix Foundation put more protections in place or even give an indication of wanting to do so anyone reading this should consider element and the matrix protocol open to abuse/spam and not worth using.

@konomikitten have you considered that one can block matrix.org? If you're using Element as client you can also use it's option in labs to use policy lists as block list, and wildcard ignore @*:matrix.org, which will reject any invites from matrix.org users.

Edit: didn't mean to imply any bad blood towards the matrix.org staff, I have to admit I've had a positive time working with them related to these kinds of attacks.

konomikitten commented 1 month ago

If you're using Element as client you can also use it's option in labs to use policy lists as block list, and wildcard ignore @*:matrix.org, which will reject any invites from matrix.org users

Does this only ignore invites or will I be ignoring my friends and contacts who also reside on the matrix.org server?

TheArcaneBrony commented 1 month ago

They work as regular /ignore's, so i'd guess so? alternatively you could use the glob pattern on mxids, eg @*badword*:* would block all mxids containing badword on any server

supakaity commented 1 month ago

Hey @turt2live, some of the thoughts I've been having about this issue:

Even just having the ability to (silently?) drop, reject or blur/mask invites at the client level where the contact isn't in a room that you're in would be good as a first stage.

Going further, a feature like identifying that a "User is in {a / X} room/s that you're in" or "User is a friend of {a / X} friend/s", etc as a hint to "Why am I getting this invite?" would be good, and leave the invite blurred until the invited user decides if they want to reveal the details. Especially mixed in with the ability to specify conditions for dropping/masking invites. e.g:

When user is unknown to you (cold contact):
( • ) Silently ignore invite
(   ) Automatically reject invite
(   ) Blur invite details
(   ) Display invite normally
(   ) Automatically accept invite

When user is in a room you're in:
(   ) Silently ignore invite
(   ) Automatically reject invite
( • ) Blur invite details
(   ) Display invite normally
(   ) Automatically accept invite

When user is a contact of an existing contact:
(   ) Silently ignore invite
(   ) Automatically reject invite
(   ) Blur invite details
(   ) Display invite normally
( • ) Automatically accept invite

etc...

It doesn't remove the need for a protocol level reporting of bad actors, however a simple feature like this at the client level would allow users to have more control over the experience and not leave them feeling as vulnerable and powerless as they do at the moment.

Additionally, from the bad actor's side, knowing that they can be/probably are being ignored can reduce some of the "thrill" they receive at exploiting an unbalanced power dynamic, by empowering their targets, thus disincentivizing the "reward" they get for their bad behavior.

element-hq / element-meta