Add E2EE-Off Config to matrix spec

[Bun-Bun]

End to End Encryption is complex and confusing for the average user. If a user doesn't understand all of the implications it is very easy for data to get locked behind encryption and inaccessible to the user.

In a business/corporate setting using a closed off non-federating server having data locked out in this manner is a deal breaker. Business policy can require data to remain accessible to the appropriate people at all times. As well as the support headache of having users getting locked out of business data with no way to rectify the problem.

Currently synapse has no official method to disable E2E Encryption matrix-org/synapse#4401

The current workarounds to my knowledge are block the encryption calls with a reverse proxy and/or modify the default room power levels for enabling encryption matrix-org/synapse#4367

Both result in errors being displayed to the user and IMO are fragile solutions.

After several discussions I have determined that people agree this is something that needs to be configurable and should be dealt with at the spec level so that it can be handled appropriately at every level.

I propose adding an option to the synapse server config that fully disables encryption and cross signing. This variable could then be communicated to the clients which would then in turn hide the encryption settings making for a seamless user experience. This variable could benefit from being non binary. ie. Have 4 options: enforced off, default off, default on, enforced on. This should cover the wide range of applications for a private server.

I apologize I didn't use the spec proposal process, I am not a developer and that process is far to complex for me to complete.

Another reference element-hq/element-web#13537

[KB1RD]

I think that Matrix could be super useful at a makerspace where I volunteer and I'm advocating for one to be set up. However, if customers are granted access, this creates the issue of how to prevent harmful content on the server. Moderation and federation limitation can prevent people from distributing/accessing such content in larger rooms, but it would be much more difficult to moderate DMs. It could be possible to resolve any issues that could occur if DMs can be accessed, but E2EE provides a barrier to this. This is much the same issue that schools would encounter when trying to use Matrix. Such a feature could be quite helpful in such settings.

However, there are also cases where enforcing E2EE could be helpful, such as in healthcare or financial institutions. In both cases, it would be possible for people to violate these requirements by sending custom events and/or using modified clients. Still, I think that having a mechanism that makes it clear that E2EE is or isn't supposed to be on will prevent cases where E2EE settings are accidentally changed or where one party turns on E2EE without the knowledge of the other.

[Bun-Bun]

I added to the original post

This variable could benefit from being non binary. ie. Have 4 options: enforced off, default off, default on, enforced on. This should cover the wide range of applications for a private server.

[abhishekgupta92]

Is there any plan to add this to the roadmap some time? This does seem like a very important feature for many reasons.

[Bun-Bun]

matrix-org/synapse#7639 and matrix-org/synapse#2431 added config options for e2ee but completely ignored all the requests to disable e2ee.

I thought I had done this the proper way but it is continuing to be ignored by the dev's. What does it take to get the devs to take users seriously?

[turt2live]

We are listening to feedback in general, however the spec doesn't change overnight. Pursuing this from a spec route requires an MSC and time, which is likely going to have to come from the community given current priorities the core team is juggling.

[Bun-Bun]

I understand the spec doesn't change over night, but the config option that pertains to how encryption enforcement is handled at the server level was being worked on within the past week. Why wasn't this option even considered/talked about? It could have been added as a part of matrix-org/synapse#7639 and later fully rationalized in the spec.

Owners of private servers are stuck in a state of not being able to update and are in a dangerous position right now.

[turt2live]

I can't speak for the synapse team, however from the looks of it the option went through as a different requirement and thus didn't have expanded scope.

Asking for progress on Synapse issues from the spec side is largely unproductive and highly unlikely to get noticed.

[Bun-Bun]

Asking for progress on Synapse issues from the spec side is largely unproductive and highly unlikely to get noticed.

Then where should it be done? I went into the matrix channels asking how this should be done and was told to make a issue on the spec.

There are other issues on this topic asking for the same thing in Riot and Synapse and those are being ignored as well.

[turt2live]

Honestly, this won't progress at all at a spec level without an MSC. For Riot and Synapse, talk to the individual projects. The spec doesn't favour them over other implementations - anyone can open an MSC, run/build a different server, or use/build a different server.

[syldrathecat]

I think this is a notable omission in the spec right now. The section "End-to-End Encryption" says "Matrix optionally supports end-to-end encryption", which seems to imply that the entire feature is optional, and while its clear how a client can not support it, there's nothing that explicitly indicates how a server could choose to not support it.

The section "Common error codes" says that any endpoint may return M_UNRECOGNIZED -- "This is expected to be returned with a 404 HTTP status code if the endpoint is not implemented" -- however returning a 404 error for any of the API endpoints under /keys/ causes a critical failure of all major Matrix clients tested.

Example: Element Web/Desktop will hang on "Syncing", while repeatedly calling /keys/upload.

Because the spec lacks guidance of how a server could choose to not support E2EE, clients are assuming that all servers are capable and willing.