| 23 May 2025 |
 BeatLink | ive heard horror stories of facebook moderators seeing all kinds of horrible crap | 07:48:57 |
 uep | there are already reasonable mechanisms for publishing and sharing blocklists | 07:53:36 |
| uep | and out bot shares (both inbound and outbound) with others | 07:54:21 |
| uep | but it doesn't apply to invites, and there's no real way for clients to use them, and the format is a bit limited so you can't use things like patterns for usernames | 07:55:40 |
| uep | and all the other things, like deleting images, are reactive and subject to lag and the vagaries of matrix being inconsistent | 07:56:32 |
| uep | so, for example, someone has been creating thousands of <hex-hash-guid>:home.server usernames, and sending spam, and they get added to the shared blocklist, so the bots dutifully add them to the block lists of all the channels they're protecting | 07:58:45 |
| uep | and i'm sure at some point this is going to be a new attack against matrix servers when those are too long | 07:59:13 |
 Cat | In reply to @uep:matrix.org
but it doesn't apply to invites, and there's no real way for clients to use them, and the format is a bit limited so you can't use things like patterns for usernames There’s tech that’s rapidly maturing into stable releases that deals with this tho. | 08:00:08 |
| Cat | It’s tho a ask your homeserver admin | 08:00:19 |
 Zhaofeng Li | Has there been any discussion about moving to... libera.chat? I know we will essentially be moving "back" but still | 08:00:36 |
| Cat | Draupnir has in beta the capability to pre emptively with HS support block known bad invites and clean them up also | 08:01:06 |
| Cat | And there has already been work started on implementing the policy server backend in meowlnir and I wouldn’t be shocked if it lands in Draupnir eventually too | 08:02:28 |
| uep | meowlnir.. lol | 08:03:23 |
| Cat | Tulir loves cats. | 08:03:43 |
 emily | to be clear, this is the second phase | 08:05:15 |
| emily | the first phase was joining the rooms directly and spamming CSAM/gore | 08:05:22 |
| emily | coupled with DoS targeting federation so that deletion events for the messages didn't get propagated quickly | 08:05:38 |
| emily | (and even when they do, homeservers and clients don't purge media from caches by default on deletion, so it's too late to prevent illegal material propagating to the storage of hundreds of machines) | 08:06:11 |
| emily | that's why we went invite only | 08:06:17 |
| emily | the invite spam is quite a bit less bad than that was frankly | 08:07:32 |
| Zhaofeng Li | In reply to @emilazy:matrix.org
(and even when they do, homeservers and clients don't purge media from caches by default on deletion, so it's too late to prevent illegal material propagating to the storage of hundreds of machines) on that note, what's the solution now? I think a few years back we were sharing media IDs to be deleted manually | 08:09:38 |
| uep | for the most part it's just "delete remote images" from the cache.. and hope the spammers aren't your own users | 08:11:16 |
| uep | which of course has other impact on genuine users and content, so the spammers win regardless | 08:11:51 |
| Zhaofeng Li | ok, good to know | 08:12:09 |
| emily | for deletion, yeah I think it's basically complete purges. for what you are legally required to do per jurisdiction – I wouldn't want to comment honestly | 08:12:44 |
| emily | my impression is that for CSAM the legal requirements are sufficiently strict that "there was this spam wave and Matrix makes it really hard to purge this stuff" is not going to mean anything. OTOH I also hear that in some jurisdictions deleting isn't enough, you have to proactively report it. which seems completely untenable in this case | 08:13:26 |
| uep | (and whatever each client uses for clear cache, too) | 08:13:36 |
| emily | so, uh, I guess the safe advice is stop running a homeserver? | 08:13:39 |
| emily | …or a client? | 08:13:44 |
|  Suwon Park joined the room. | 08:17:13 |
