Refuse cleartext on my homeserver

[lofidevops]

User story: I am a system administrator setting up a homeserver for strangers. I want to ensure that I never have access to the content of their communication, so they don't need to trust me.

Is it possible to configure Synapse so that my homeserver never handles unencrypted content. I can accept that some so-called metadata may be visible (separate question to find out what that is :)

Scenarios:

In all cases users should be able to connect and chat, without me seeing their messages:

• @alice:myserver.com talks to @bob:myserver.com
• @alice:myserver.com talks to @carol:elsewhere.net
• @alice:myserver.com, @bob:myserver.com and @carol:elsewhere.net chat
• @alice:myserver.com joins #matrix:matrix.org (a pre-existing unencrypted room) to chat

Notes:

• Overhauled this ticket to make the requirements clearer.
• Related: Purge old cleartext on my homeserver #2964

[Half-Shot]

It seems like you are asking for homeserver-wide policies on state events (and mandating that joined rooms / created rooms contain the state to enable encryption). This is not possible on Synapse and would require quite extensive modifications, and would be somewhat impossible to mandate over federation.

[Half-Shot]

In theory...you could. A homeserver can infer if a room is encrypted and you could reject a join request on that basis.

For local rooms, you just ensure the room is set to encrypted upon creation (which definitely will screw with bridges/bots)

[lofidevops]

I've overhauled this ticket to make the requirements clearer, and deleted my previous comments. Is this currently possible? If infeasible on Synapse should I post a similar query on the Dendrite project?

[lub]

In all cases users should be able to connect and chat, without me seeing their messages:
[...]

• alice:myserver.com joins #matrix:matrix.org (a pre-existing unencrypted room) to chat

If alice:myserver.com wants to chat in an unencrypted room, you have to store her and other people's unencrypted events. You would have to block most of the matrix network (almost all public rooms) for your users.

This behavior is not Synapse specific and caused by the fact, that federated rooms are decentralized and stored by all (room) member servers.

Edit: Sorry for mentioning you alice.

[lofidevops]

@lub Thanks for the feedback. Does it make sense to distinguish between "public rooms on other servers" (like #matrix:matrix.org) and "rooms on my server" (like #room:myserver.com)? I guess I could store data that is "public anyway".

[Half-Shot]

You would have to block most of the matrix network (almost all public rooms) for your users.

Speaking to @maxidor who spends most of his time with his head in the federation rabbit hole, you can ask for room state without being joined. So you could build a custom synapse that asks whether a room has the crypto flag set (remember, once encrypted a room should never be de-encrypted) and join it that way.

I'm not sure if this will catch every case, and i'm sure you could probably find ways to exploit it but it goes a long way to hitting on what @kwill want's, I think.

[Half-Shot]

As @lub says though, that leaves you with a tiny fraction of rooms avaliable to you. This would be almost a pure PM server as the vast majority of my (many) rooms that I am in, are plaintext.

[lofidevops]

In summary, this is not implemented, feasible, but rather limiting in terms of functionality. Specifically, users wouldn't be able to access public-access cleartext rooms.

[rubo77]

Where is this overhauled?

I think it is a great idea to completely disallow unencrypted rooms.

[lofidevops]

@rubo77 This evolved into a discussion with @ara4n with the final idea is expressed at #3269 (Support only E2E or public rooms on my homeserver). In other words, users on homeserver X can create/join E2E rooms or public-access cleartext rooms, but cannot create/join access-controlled cleartext rooms.