Synapse: Ability to disable End-To-End Encryption via Config

[neilisfragile]

Description:
Originally proposed in #4367 - for the case of #4367 is was sufficient to address via power level settings. Creating a new issue to track doing this via a config setting.

The original ask:-
"I would like the ability to disable end-to-end encryption in my self hosted Synapse instance. I have a legal requirement to provide audit-able chat logs, which is obviously impossible if there's nothing preventing my end-users from encrypting any room they create."

[gordon-quad]

Maybe better approach could be to set default power level settings through config?

[Bun-Bun]

I also would like this option. The way encryption is handles is far too confusing for my users and I do not want to deal with them getting locked out of their messages.

[cnvandijk]

Related: #6660.

[mlaily]

This feature is becoming more urgent now that Riot has enabled encryption by default.

I have a home server for family and friends, and I'm glad I can self host a chat server matching commercial instant-messaging in quality, but I really can't justify to them the need for end to end encryption, given the hassle and risk (of losing data) it adds!

IMO, https is largely sufficient for my security needs, given I can trust the server (because I own it).

[Bun-Bun]

I agree with @mlaily. As it stands I am scared to update any of my infrastructure in fear of rooms getting automatically encrypted and my users losing access to business data.

[MurzNN]

What happens if we simply disable m.key.*, m.room.encrypted and m.room.encryption endpoints for local Synapse instance via nginx proxy? This will disable creating keys and E2EE rooms on server, or not? If not, which other endpoints can we block for disable all E2EE stuff?

[erikjohnston]

You can use the spam checker or third party rules plugin modules to disable/filter out events related to encryption, which is probably easier than relying on rules in nginx

[MurzNN]

Thanks for idea, I fill feature request about this in https://github.com/devture/matrix-corporal/issues/8

[anilk9096]

hi ,
we had blocker with this . when can we expect this or please suggest any alternative way to disable this .

[anilk9096]

user are confusing to verify with lot of process

[mlaily]

Same. I don't want to upgrade until e2ee is easier, or until it is possible to make it so clients (Riot) don't try to force me to use it.

[anilk9096]

Even using old version . Even skipping encryption setup keys first time login for some user getting default enabled encryption why ?

[clokep]

It does not fully solve this, but #7639 added a config options for whether new rooms default to E2EE or not. Note that this will be available in the next version of Synapse.

[Bun-Bun]

7639 doesn't fix it at all.

The client can still default/force the room to be encrypted. We need an option to fully disable/block e2ee on the server.

[mlaily]

It does not fully solve this, but #7639 added a config options for whether new rooms default to E2EE or not. Note that this will be available in the next version of Synapse.

That's good, but what about not bothering users to setup recovery keys and verifications upon login? (I'm more interested in not bothering clueless users, compared to preventing them from enabling e2ee if they want to)

[Bun-Bun]

It does not fully solve this, but #7639 added a config options for whether new rooms default to E2EE or not. Note that this will be available in the next version of Synapse.

That's good, but what about not bothering users to setup recovery keys and verifications upon login? (I'm more interested in not bothering clueless users, compared to preventing them from enabling e2ee if they want to)

That specifically is a client issue, aka Riot. However that ties into the Synapse config variable which the devs completely ignored the option to disable e2ee

[richvdh]

@Bun-Bun complaining in 15 places that we haven't implemented your favourite feature is unlikely to make us consider your request favourably.

As far as I can tell what you are demanding is https://github.com/vector-im/riot-web/issues/8067, which is only tangentially related to most of the PRs you have commented on.

I realise you are frustrated, but that does not excuse your rudeness.

[anilk9096]

hi clokep. thank you for response. Tried building dev branch code with #7639. I thought off will work :) . but it was not use full at all. kindly try to give option to disable encryption in private or direct chat like when creating in group . thank you very much

[Bun-Bun]

@Bun-Bun complaining in 15 places that we haven't implemented your favourite feature is unlikely to make us consider your request favourably.

As far as I can tell what you are demanding is vector-im/riot-web#8067, which is only tangentially related to most of the PRs you have commented on.

I realise you are frustrated, but that does not excuse your rudeness.

I apologize for complaining in the matrix-doc issue and in the Synapse channel. I am not a developer and exactly how PR's and issues are supposed to work is unclear to me.

Please try to understand my frustration. When I first indicated my support for the option to disable/block e2ee it was more a want as at that time I was satisfied with the workaround patch to rooms.py as discussed here https://github.com/matrix-org/synapse/issues/4367 However that changed when riot-web defaulted to encryption on, which given the way regular users work is effectively forcing encryption on. As indicated in https://github.com/matrix-org/synapse/issues/4367 that change broke the rooms.py workaround as it prevented direct chats from even being created. I see another user figured out an additional patch to workaround it again however that doesn't change the larger issue. The concept of default on e2ee is breaking for admins of homeservers like mine where company policy or legal obligations dictate that all data be auditable. Further on that point e2ee is complicated and confusing for regular users and can very easily lead to employees being locked out of business data with no way for the server admin to correct it.

At that time I raised the concern here https://github.com/vector-im/riot-web/issues/6779 and had discussion with t3chguy as well as in the various support rooms on matrix.org. t3chguy (a riot dev?) raised a very good point and I 100% agree with him. The switch controlling e2ee behavior needs to be on the server side so that the behavior is enforced at the homeserver level and clients can be configured appropriately. After further discussions the general consensus was this is a option that should exist but it really involves the matrix spec and I was pointed to that repository. I created an issue there and revised it to add options for other use cases that other users raised concerns over. It appears to me and other users that the issue I created has gone completely unnoticed and/or not considered. In my opinion https://github.com/matrix-org/synapse/pull/7639 and https://github.com/matrix-org/synapse/issues/2431 were directly related, as they are adding the option to control e2ee behavior, much to how I described the options in my matrix-doc issue, and were the perfect opportunity to explore and add this option to the synapse server. Which is why I asked there why the disable option was not considered.

Then I joined the synapse channel and asked how we can get this issue escalated and yes that conversation quickly degraded and after the link to the vector.im contact page I left as nothing productive was happening in that conversation.

Now faced with riot dev's telling me it's a synapse/spec issue and the spec guys saying there isn't any resources to do anything about it and synapse guys pointing it to be strictly a client issue I can't help but feel everyone is just passing the buck and I'm in that annoying support phone call loop of being transferred from department to department with no resolution. One thing I did get out of the synapse conversation is this was done https://github.com/vector-im/riot-web/blob/develop/docs/e2ee.md which is a great step in the right direction and I started exploring it's discussions. Even though the riot guys (or maybe only t3chguy?) think this is a server side issue they are the only ones discussing this or at least the riot repository is the only place I've seen said discussion. Specifically this post https://github.com/vector-im/riot-web/issues/13539#issuecomment-630310291 which led me to the related PR and issue https://github.com/matrix-org/matrix-react-sdk/pull/4605 https://github.com/vector-im/riot-web/issues/13705 which had great work done on not only adding a config switch but how that change impacts the UI and how the user experience is affected. In my opinion disabling e2ee again is directly related as it has the same considerations with UI and user experience as well fits in with that .well-known config switch. Should it be handled at the homeserver level? Yes absolutely but the only place that any devs seem to be discussing these issues is on the riot repository hence why I asked the question there. I think at least for short term viability a riot-web config will help admin/users and spur further discussion to implement it properly.

I wish more than anything I had the capability and capacity to contribute directly to the development of these projects, but I am not a developer and I have my own team to manage. My use-case is for business and now that I know about vector.im I do plan to reach out and learn more about how I can support these projects and sponsor the features I and others need. These issues date back more than a year with no indication of any progress or consideration other than the mentioned riot-web issue/pr. That said, do you understand how frustrating it is from an admin/user perspective to have these independent yet closely intertwined projects pass the buck and have questions about how to escalate issues result in arguments about semantics? I am not demanding https://github.com/vector-im/riot-web/issues/8067 (especially since that is on the riot-web repository but it should be added to synapse) but rather asking how do I get this issue to the attention of the appropriate people? How can I help as a non developer?

[mlaily]

Hum. That was a long rant. :)

The hard truth is that this is a free and open source project and the devs don't owe us users anything.

I wish the issues I care about (this one in particular) would be assigned more importance and priority, but ultimately, this is a free an open source project, and even if it is frustrating, I think we should understand that if our priorities don't match the devs' ones, this might not be the best project for us to use. (Unfortunately for me and maybe you, this project is still the closest to my list of prerogatives for a self hosted IM...)

[Bun-Bun]

Yes I understand that, which is why I am going to explore supporting the project through vector.im. I didn't know that was an option before.

From my perspective it seems this issue hasn't gone through the proper channels and is sitting in limbo which is why directly related issues/pr's got processed without even considering this one. But maybe I'm wrong and there actually is intense discussion around this behind the scenes. All I am trying to do is figure out how can we get this where it needs to go, pissing off dev's is not my intention. That is why I am asking how can I help. What does this need?

EDIT: And to your point about other projects, yes Matrix is the clear winner and only project in my opinion that has a good future. Which is why I want it to succeed. I hate that the answer is always Slack or Discord since all the other open projects are either too complex, have crap all for client support (and thus poor user adoption) or don't support modern features that users want.

Personally I would be fine sticking to IRC but most people don't agree with me. And I get it.

[chaosgrid]

I want to add to the frustration of Bun-Bun another real world example of our org. I think the want for this feature is a spectacular failure of end-to-end encryption implementation in the current Element clients coupled with the frustrating decision to enable e2e by default for direct messages in its current form.

So here is the deal: I would have no issue with this if our users could be using e2e with minimal hassle, but as it stands I'd like the option to completely disable and hide it from the Element UI. Why cant it be as simple that you have one extra pin, which may be a 4-digit pin and not some 12+ character passphrase - like Signal on Android is doing it? Why is key-backup and cross-signing two different things? While I may understand these things as a computer science guy, average users cannot - hence the need for this feature to completely disable it for the time being.

I think e2e needs a major overhaul from a UX perspective and while it got better in the last updates, it should not be forced on users as it is now because this simply leads to lost messages and broken user accounts - and then users get discouraged from using e2e ever again - the worst case.

[menturion]

+1
Ideally, E2EE should run completely in the background, without any required user interaction with a single modifiable passphrase for logon authentication and E2EE.

[Bun-Bun]

@chaosgrid I agree 100%

Though I would like to stress that for this particular issue that a server option is needed regardless of whatever improvements are made to e2ee as mine and many others company policy requires that information remain audit-able and e2ee breaks that. A way to disable e2ee that is supported without requiring ugly hacks is needed.