Consider handling server ACLs through event auth rules rather than at the network level

[anoadragon453]

The topic of why server ACLs act at the network level, and not the event auth level came up in discussion today in #matrix-spec. Summarising the conversation, handling ACLs in event auth mean that:

• locking it to a room version, which has the side-effect of knowing that all compliant homeservers in the room should support server ACLs.
  • This can prevent events from "leaking" out of servers that don't support server ACLs.
  • Room participants will have a simple way to check if all homeservers in the room support server ACLs, instead of checking homeserver implementation projects and version numbers.
  • This will boost support of server ACLs in homeserver implementations, as it will be necessary to participate in newer room versions.

The original proposal for Server ACLs noted that doing so at the network level was done for the sake of time - however @richvdh commented that a DAG-level ban would be ineffective. I'd be interested to know why?

[richvdh]

gosh that was a long time ago :/. For internal folks, there was discussion of this in an old room at https://matrix.to/#/!ciirqRAoioaytTwWEQ:matrix.org/$1530540612198SvWYT:sw1v.org?via=matrix.org&via=sw1v.org&via=t2l.io.

A summary of the reasoning is:

Basically, if the ACL applies at the DAG level, there is nothing stopping an ACLed server generating join events etc based on an old point in the graph. This is mitigated to some extent nowadays by soft-fail, however an ACLed server would still be able to, for example, cause a DoS by injecting thousands of state events into the room.

Similarly, one of the goals of ACLs is to protect rooms from abusive manipulation of the state resolution algorithm. By preventing an attacker sending events at all, we dramatically reduce their ability to abuse state res.

There may well be an argument for both approaches.

[ShadowJonathan]

The original proposal for Server ACLs noted that doing so at the network level was done for the sake of time

With some idea of what happened around that time, my opinion is to "rectify" this with the suggested approach of baking this into the stateres, but as rich says;

Basically, if the ACL applies at the DAG level, there is nothing stopping an ACLed server generating join events etc based on an old point in the graph.

This is true, but a new proposal could suggest points of "short-circuiting" as an optional preventative measure, in the same vein as it is the primary measure nowadays.

To summarize;

I think that ACLs should be primarily and firstly recognised in a context of stateres, but for the wider DoS context it exists around, it should "inform" federation relations with that server as it does today, in a similar vein to SMTP Error 421, "4.7.0", "Try Again Later".

A server could keep track of all servers that are currently on a ACL list through valid stateres, put them on a "short list", quickly match against that list when fetching or receiving incoming events, and possibly pre-emptively reject state-like events out of hand.

This above approach would be optional, enhancing the core protection that the stateres approach would provide, if the developers deem that fit.

[Mikaela]

Do I understand correctly that something has been done here recently or will be done in near future considering Element blog is just mentioning that ACLs exist?

• https://element.io/blog/moderation-needs-a-radical-change/

I have also blogged about other moderation issues.

[Mikaela]

As my previous question went unanswered and Matrix.org blog mentions this now:

There’s a recent write-up of the proposed approach for Matrix at https://element.io/blog/moderation-needs-a-radical-change/, which outlines one strategy - but there are many others. Honestly, having to improve moderation tooling is a worthwhile price to pay for the benefits of open APIs.

I would like to ask is this still Element Marketing Team in action, or are these issues becoming a priority to Matrix Foundation too?

[Gnuxie]

Hey everyone, I have created MSC4124 with some simple authorization rules that consider the origin server of events.