This post follows an introduction to Matrix with e-mails, where I explain that Matrix is a federated system.

Federation can be either public or private. A public server can communicate with any other server, except the ones which are explicitely avoided. Meanwhile, a private server can only communicate with a selected list of other servers.

Private federation is often deployed between entities that can trust each other, for example between universites. Often there are processes to take back control of things when they derail on a server you don’t manage, because people on the remote server are contractually bound with you.

But many organisations, and especially open source projets, deploy their instance in public federation. This means strangers from the Internet can interact with your server. Public federation comes with its own set of non-technical risks.

In this post I’m going to guide you through the problems we faced on our GNOME Matrix instance. For each problem I’ll bring a solution. They will be consolidated at the end of the post in the form of a target we want to reach eventually, along with the acknowledgement of the limits of what we can do. Please note that these problems have more to do with careful planning and deployment than with the Matrix protocol itself.

Registrations open

When the GNOME instance was first deployed, people were much more used to IRC than Matrix. IRC does not really federate: it actually replicates information on several servers, forming a completely isolated cluster. Different clusters cannot interact with each other. The goal is more high availability than federation. On such clusters, guest mode and even registrations are often open. It was decided to keep registrations open on the newly deployed Matrix instance. While it makes things convenient for people who are not used to Matrix to come and say hi, having registrations completely open is often not desirable when running a Matrix instance. Let’s cover the main issues.

Impersonation

One of the first and most critical threats we face is the risk of impersonation. In the introduction to Matrix I compared it with e-mails. We can follow the same thinking here: we don’t open registrations to get an e-mail address with a @gnome.org to anyone who wants it. We shouldn’t do it with Matrix either. It opens the door for malicious actors who would want to launch phishing campaigns with an actual GNOME e-mail address/Matrix ID.

The impersonation doesn’t stop at people. The way our instance is configured today allows everyone with an (easy to get) :gnome.org account to create a room and give it an address ending with :gnome.org. This allows malicious actors to create rooms with misleading names for phishing attemps. One could indeed create a #user-support:gnome.org room and try to get other users’ credentials or payment information.

Spam

IRC has become quite famous for having low bounds to prevent spam. It is quite annoying to get its IRC network spammed, and actually… the same could happen on a Matrix instance with guest accounts enabled and no protection. The limitations to avoid spam on Matrix with registrations open are pretty much the same as on a properly configured IRC: rate limiting. This means that with registrations open, someone can create only a few accounts per day with a :gnome.org Matrix ID and send (a few) messages in many rooms. This is spam from a :gnome.org account to rooms with a :gnome.org address. While this is already not great, more embrassing events can happen.

People can create an account with a :gnome.org ID and go litter rooms that have nothing to do with GNOME. If a handful of accounts do it, they risk individual bans. If many accounts are used to do it, we’re at risk of getting our instance blocked by many other instances. In terms of PR, getting our name bound to spam and annoying actions is really not great. In terms of collaboration with other projects, being an active risk for user safety and comfort is far from ideal.

One last threat in the spam section is the directory: anyone with a gnome.org account could publish a room to the directory. Even if Spaces are thought to supersede directories eventually, they still have a long way to go. Allowing everyone to publish to the directory allows spammers to create rooms and promote them as “official” rooms. We have restricted very tightly who can publish to the directory for now, and will loosen the restrictions when only Foundation members have a :gnome.org account.

Freeloading & resources consumption

You may remember from the introduction to Matrix with e-mails that I compared matrix rooms to e-mail threads: each server of people participating in the conversation gets a copy of the conversation. If too many people join too many rooms with too high trafic, then the consumption of resources is going to skyrocket. In the same way we don’t provide e-mail for everyone or limit our Gitlab access to GNOME-related projects, we cannot afford to allow everyone to get an account on our Matrix instance.

Closing registrations

The solution to all of those threats is to close registrations and limit account creation to members of the GNOME Foundation and regular contributors to the GNOME project.

What about others? It’s once again quite close to e-mail: you don’t need a @gnome.org address to be in an e-mail thread with @gnome.org participants. Getting an account on a third-party instance allows people to join GNOME rooms seamlessly.

Additionally, it’s possible to restrict who on our GNOME instance is able to add a local :gnome.org alias to a room, but this shouldn’t be necessary in the long run.

Opening guest accounts?

An alternative solution I would love to deploy but which is not viable today is guest accounts. Guests accounts are sorts of temporary accounts: you register for an account without being able to specify a username and password. The server assigns you a username, and you don’t have a password because those accounts are supposed to be temporary.

Synapse, the most mature homeserver implementation to my knowledge, still has a few issues with them: they don’t expire and can end up cluttering rooms, and they are not excluded from user directory search results. Suboptimal, but not exactly a blocker.

One blocker is we can’t prevent guest accounts from spamming other instances. Since rooms don’t belong to a single server but are distributed in the Matrix universe, it’s not possible to develop a feature like “guest accounts should not be able to leave the server”. A smarter way to achieve what we want would be to allow guest accounts to join rooms only if there already is a :gnome.org alias bound to this room. This is something the homeserver of the guest account needs to enforce and doesn’t require a change in the Matrix specification for that. Unfortunately no homeserver implementation support this feature (so far?). I have opened an issue on Synapse to discuss whether such restrictions would make sense or not.

But guests accounts suffer from another major blocker: neither Element (the most popular web-based Matrix client) nor Fractal support guest account registration and usage. Riot, the ancestor of Element, used to support them, but somehow the feature got lost and Element only supports read-only mode for guests as I’m writing this article. Incremental Signup seems to be in Element’s roadmap for 2021. While the feature is not exactly what we want, there are synergies we could benefit from (i.e. being able to actively participate as a guest). Fractal’s maintainers also confirmed that guest account registration and usage would make sense in Fractal, and I opened an issue to keep track of it. Of course, the focus for Fractal Next right now is on feature parity with Fractal and E2EE support.

Losing ownership

Because of the decentralised nature of Matrix, ownership of a room and how to manage it can be difficult to grasp.

Giving administrator rights

Granting someone else administrator rights on a room should actually be called “sharing ownership”. Granting someone administrator privileges on a room means giving them power level (PL) 100. You cannot demote someone who has been granted the same power level as you. So unless they voluntarily decide to give it back, you can’t take ownership back even if they turn out to be not as nice as you expected them to be.

It’s bad but retrievable when the new room administrator is on the same server as you and doesn’t respect your server’s policy. The server administrator (not the room one) is able to impersonate people from his server, to make them demote themselves. Taking back administratorship/ownership of a room is not possible from a sole technical perspective when someone from another server has been granted administrator rights.

I opened an issue on Element Web’s bug tracker and on Fractal’s one to replace “Administrator” with “Owner”. I believe this can make the consequences of sharing administrator rights more obvious, but it is not a proper solution to prevent the issue from happening.

Removing the last administrator

It is only possible to grant someone a power level you already have yourself. For example, a moderator (PL 50) cannot grant someone administrator (PL 100) rights. When the last administrator leaves a room, nobody has the PL 100 anymore, making it impossible to grant someone administrator rights ever again.

Why won’t the homeserver administrator just take back ownership of the room then? Because they cannot. Rooms on the Matrix universe don’t belong to a server, so nobody can take over a room even with server administration privileges. Note, in the very specific case of the last administrator leaving the room without demoting themselves first, it is possible either for the last administrator to join again and grant privileges to someone else, or as a very last resort for the server administrator to impersonate the last room administrator to do so. For all other cases, it’s not possible to retrieve it and the room cannot be controlled by anyone ever again.

An apparently simple solution to circumvent this problem would be to ask people creating a room on GNOME’s homeserver if they want to share ownership with the @moderation:gnome.org user. This would make sure that the moderation team is still able to appoint someone else as administrator in the room. But this absolutely need to be opt-in, because it opens the door to potential abuse by the moderation team: they would be technically able to see end-to-end encrypted messages, since the @moderation:gnome.org user is one of the ends! This is definitely not something you want when you create a room to have a private chat with somebody. What we do now is we offer people who manage rooms about GNOME-related projects to share ownership with that moderation user, but the process is not automated at all.

Our target

Closing registrations

We have seen that closing registrations is a must have for the GNOME Foundation to get back sovereignty on its domain. Since it can be unsettling for people not used to Matrix to register on a third-party to be able to join, we would like to open guest accounts in the longer run. As mentioned earlier, proper mechanisms to prevent outbound spam with guest accounts don’t exist yet.

Asking people nicely to find another provider

When closing registrations, we want to prevent new joiners from being able to impersonate Foundation members or to create room aliases for phishing. But we will also unfortunately need to ask non-Foundation members to get an account on a third-party provider. Important note: we are not yet asking non-Foundation members to find a Matrix provider for their personal account for now, but will eventually have to.

Of course, people can’t be asked to get a new account just like that. We need to explain our choices properly, and help them during the transition. We need for example to anticipate those questions and document the answers:

• Why are you closing registrations? Why were they open in the first place?
• What are good places to register an account?
• How to migrate the data from my unofficial GNOME account to my new personal account? Can I mess it up? Should I take extra care of something in particular in the process?
• Will I lose anything in the process?

Mapping existing accounts with our on-premises LDAP

Today, our instance is hosted and managed by Element Matrix Services. We are very satisfied of the service they provide: they even have helped us significantly during the fake Libera Chat spam wave!

The GNOME Foundation has a policy to self-host all the things, and Matrix is not an exception to that. The GNOME Foundation didn’t have an “official” chat platform, but we’re aiming at changing that. We are waiting for our Executive Director to examine the results of chat survey carried out in March and make a recommandation to the board who can approve it. At this point, Matrix seems to be the choice of platform that makes the most sense for our needs.

If Matrix is finally made the recommended platform, we will be able to move it back on-premises, and map existing accounts with our on-premises identity systems. Note that since we already have existing accounts on our Matrix homeservers, mapping them to the LDAP probably will require fiddling with the database for it to be done properly.

Important update: the GNOME Foundation’s systems administrators decided to keep relying on EMS and not get our Matrix instance back on-premises because of the excellent service they have provided, in particular during the spam waves we faced. Our systems administrators are deploying a Keycloak instance so we can use our GNOME Foundation credentials to authenticate on the instance hosted by EMS by using OpenID Connect. More on that in a blog post soon!

Room for improvement

Some of the concerns raised in this article don’t have a solution yet. I consider the one about guest accounts to be a low hanging fruit: it would allow us to keep a nice experience for people who just want to pass by, and doesn’t seem too difficult to implement. But there are no proper solutions, not even from a functional perspective, to address the problem of granting a too high power level to other people on our rooms. We also don’t have an automated way to prevent losing the last administrator in a room.