openSUSE admin

Synapse supports banning servers on a per-room basis via room ACLs, See "Banning servers from rooms (Server ACLs)" in https://matrix.org/docs/older/moderation/. This cannot be done via the Element UI, but the page documents how this can be done via development tools.

Hi,

I wanted to raise a few points:

• matrix.org is not a major source of spam in this incident (from rough memory maths, m.org only accounts for 10% or less of accounts)
• Blocklisting matrix.org in Synapse is kind of pointless:
  • It breaks existing DMs, non-opensuse rooms
  • it does not stop matrix.org from sending messages at all, and they will still happily arive on opensuse.org, but only delayed but someone else sending a message
  • it makes m.o.o blind to matrix.org traffic -> m.o.o moderators cannot respond to events originating from matrix.org
• Similarly, using Server ACLs has flaws aswell:
  • These are executed at network layer, not event authorisation
  • -> Only takes one server in the room not execting server ACLs or missing the ACL event to leak matrix.org events back into the room

@ph03nix: matrix.org is currently ACLed in all official openSUSE rooms, but this decision may be reverted upon further discussion, regarding these points

Regards,
Emma [it/its] @ Rory& (matrix:u/emma:rory.gay)

RorySys wrote in #note-3:

Hi,

I wanted to raise a few points:

• matrix.org is not a major source of spam in this incident (from rough memory maths, m.org only accounts for 10% or less of accounts)

Granted, but they've been a repeated problem of spam/trolling in general, for a long time.

• Blocklisting matrix.org in Synapse is kind of pointless:
  • It breaks existing DMs, non-opensuse rooms
  • it does not stop matrix.org from sending messages at all, and they will still happily arive on opensuse.org, but only delayed but someone else sending a message
  • it makes m.o.o blind to matrix.org traffic -> m.o.o moderators cannot respond to events originating from matrix.org
• Similarly, using Server ACLs has flaws aswell:
  • These are executed at network layer, not event authorisation
  • -> Only takes one server in the room not execting server ACLs or missing the ACL event to leak matrix.org events back into the room

@ph03nix: matrix.org is currently ACLed in all official openSUSE rooms, but this decision may be reverted upon further discussion, regarding these points

Absolutely, this doesn't need be permanent, and it's fairly obvious that Synapse (and other servers based on the Matrix specification) don't handle this sort of issue well, and the tools are inadequate at best. That being said, matrix.org is (I think) the largest entrypoint for people to Matrix as a platform, and keeping it "blocked" just isn't really something workable long term.

Unfortunately, it looks like this is a problem we're going to need to figure out to handle ourselves, as the platform itself doesn't offer the tools other platforms do, as near as I can tell. And we just don't have enough people to be able to manually moderate all of this stuff, with the existing tools.

Historically, fair, but I am slowly working to put together some tooling to help with that.
Additionally, some moderator load is already being reduced by usage of Draupnir (enforcing bans over the entire space), and a reputable, shared banlist.

More automation, within reason, would always be nice to have. I hope I'll have something maybe by the end of the week?

Edit: I wonder if it might be useful to re-open this ticket as a tracking/discussion hub?

When you drop them from the Synapse level, what do you propose we do with the room-level blocks ("Server ACLs", applied via Draupnir)?
Alternatively, would it be a better idea to block invites from matrix.org (via reverse proxy), or rather technically: block invites to rooms created by matrix.org by matching against it in the federated invite route?

Those can equally stay until we have a satisfactory solution, they are not affected by me applying our machine configurations (Synapse, firewall, ..).
I guess, but is joining of matrix.org rooms a problem?

With the spam now having moved to federated room invites, I suggest we disable those.
As far as I'm aware, the best way to do so is to mask ~ /_matrix/federation/v2/invite/ in the reverse proxy.

@crameleon is this something that could reasonably be implemented as a temporary measure?

Yes, we can either do it on the frontend HAProxy or on the backend nginx. The former should be the most efficient, I will prepare a patch.

Once this change is made, we can remove the blacklist on matrix.org, most likely

What should we return for requests to ^/_matrix/federation/v2/invite/.*? 503 sounds reasonable, but could be misinterpreted as an unwanted outage. 403?

crameleon wrote in #note-12:

What should we return for requests to ^/_matrix/federation/v2/invite/.*? 503 sounds reasonable, but could be misinterpreted as an unwanted outage. 403?

Yeah, 403 would work fine.

https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/2080

Committed as https://progress.opensuse.org/projects/opensuse-admin/repository/salt/revisions/aaea775e8604920c76172bd0989d2be0edeeb431 and deployed. Changes in homeserver.yaml reverted.

@crameleon can you make a followup post to the Project-ML, just for completeness, and let folks know that the block has been removed?

@sfalken@cloverleaf-linux.org worth noting the room level defederation in public rooms is still active.

matrix.org has been un-ACLed due to this causing the matrix.org side of rooms to appear completely unmoderated. This probably deserves a ML post?

Posted: https://lists.opensuse.org/archives/list/project@lists.opensuse.org/message/ZHTSKFOOZMV74OHJEVEFL5TTUZUU4VOG/

Note that the proxy rule is still in place.