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

Invite spam harassment counter measures #2486

Open
konomikitten opened this issue Jul 25, 2024 · 12 comments
Open

Invite spam harassment counter measures #2486

konomikitten opened this issue Jul 25, 2024 · 12 comments
Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Critical Prevents work, causes data loss and/or has no workaround T-Enhancement T-Feature Request to add a new feature which does not exist right now

Comments

@konomikitten
Copy link

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 [email protected]. 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

@dosubot dosubot bot added A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely T-Feature Request to add a new feature which does not exist right now labels Jul 25, 2024
@emi-rose
Copy link

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

@konomikitten
Copy link
Author

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

@supakaity
Copy link

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.

@t3chguy t3chguy transferred this issue from element-hq/element-web Jul 25, 2024
@konomikitten
Copy link
Author

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
Copy link

bb010g commented Jul 25, 2024

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).

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

Other related issues I found:

@turt2live
Copy link
Member

Thanks for the ping @bb010g and detailed link tree! The spec does have matrix-org/matrix-spec-proposals#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 matrix-org/matrix-spec-proposals#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
Copy link

joshsimmons commented Jul 26, 2024

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
Copy link

TheArcaneBrony commented Jul 26, 2024

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
Copy link
Author

konomikitten commented Jul 26, 2024

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
Copy link

TheArcaneBrony commented Jul 26, 2024

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
Copy link

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.

@dbkr dbkr added the S-Critical Prevents work, causes data loss and/or has no workaround label Jul 29, 2024
@konomikitten
Copy link
Author

I just want to add to this issue that I logged in with the matrix client Fractal recently and all the abusive rooms I was spammed with are listed under Historical after using Forget Room in Element.

So having rooms persist also aids in the abuse mentioned in this issue.

Again it's super disappointing that as far as I know no progress has been made on protecting matrix users from this type of abuse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Invite O-Occasional Affects or can be seen by some users regularly or most users rarely S-Critical Prevents work, causes data loss and/or has no workaround T-Enhancement T-Feature Request to add a new feature which does not exist right now
Projects
None yet
Development

No branches or pull requests

8 participants