Ability to disable End-To-End Encryption via Config

[neilisfragile]

Description: Originally proposed in vector-im/element-web#4367 - for the case of vector-im/element-web#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."

[theslash]

So 4,5 years have passed and it's still an issue. I don't understand: is it so difficult to add an option to completely disable encryption? Or there's another reason?

IMHO this is Open Source. If it is needed PR and contributions are welcome. Alternatively, it can certainly be sponsored financially.

This is of course right. Although so many requests for this get completely shut down or ingored. Is this somewhere on the list of future Features or not?

[mhtvsSFrpHdE]

@theslash I think @grantm is trying to solve this once before, but it seems something still not right. In the meanwhile, you can try E2EE plugin until "official support" https://github.com/digitalentity/matrix_encryption_disabler/issues/10#issuecomment-1409711494

[grantm]

With the following in my homeserver config, any attempt to create an encrypted room will be refused with a 401 error:

default_power_level_content_override:
  private_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0
  trusted_private_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0
  public_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0

The "m.room.encryption": 999 lines are the ones that do the job but all values need to be specified. The values for the other events might need to be different in your use case.

When I attempted this earlier, I failed to set the overrides for trusted_private_chat and public_chat. I also ran into a bug where the permission check was happening too late so a partially initialised room got created with encryption disabled but the permission overrides had not been applied so the user could then change the config to enable encryption. That bug has now been fixed.

Another part of the solution is publishing a client config to disable encryption by default and to disable the option for the user to enable it. This means that users are less likely to ever see the 401 error. Bear in mind that the linked setting only applies to the element clients specifically and clients may ignore the contents of the /.well-known/matrix/client file anyway.

So it seems to me that Synapse does now provide the "Ability to disabled End-To-End Encryption via Config" and this issue could be closed..

[dolphinscorp]

With the following in my homeserver config, any attempt to create an encrypted room will be refused with a 401 error:

default_power_level_content_override:
  private_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0
  trusted_private_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0
  public_chat:
    "events":
      "m.room.avatar": 50
      "m.room.canonical_alias": 50
      "m.room.encryption": 999
      "m.room.history_visibility": 100
      "m.room.name": 50
      "m.room.power_levels": 100
      "m.room.server_acl": 100
      "m.room.tombstone": 100
    "events_default": 0

The "m.room.encryption": 999 lines are the ones that do the job but all values need to be specified. The values for the other events might need to be different in your use case.

When I attempted this earlier, I failed to set the overrides for trusted_private_chat and public_chat. I also ran into a bug where the permission check was happening too late so a partially initialised room got created with encryption disabled but the permission overrides had not been applied so the user could then change the config to enable encryption. That bug has now been fixed.

Another part of the solution is publishing a client config to disable encryption by default and to disable the option for the user to enable it. This means that users are less likely to ever see the 401 error. Bear in mind that the linked setting only applies to the element clients specifically and clients may ignore the contents of the /.well-known/matrix/client file anyway.

So it seems to me that Synapse does now provide the "Ability to disabled End-To-End Encryption via Config" and this issue could be closed..

Hi it seems working. Enable encryption option is grayed out. that's fine i think.

Now issue is that when we start a direct chat/message it by default encrypted. But since encryption is disabled, message is unable to send. How we can disable by default encryption. For direct message it does not prompt for option to encrypt or not. it just enable e2ee.

Is there some option can be set in homeserver.yaml to disable default e2ee enabled?

I have tried this encryption_enabled_by_default_for_room_type: off in homeserver.yaml but have no luck

[grantm]

Now issue is that when we start a direct chat/message it by default encrypted. But since encryption is disabled, message is unable to send. How we can disable by default encryption. For direct message it does not prompt for option to encrypt or not. it just enable e2ee.

You'll want to ensure that your server has encryption_enabled_by_default_for_room_type set to off.

Then you're left with a client issue. You need to configure the client to either default to E2EE disabled, or to not ask and to force E2EE to be disabled. That's what I was referring to with the client config link, which describes some entries that you'll want to add to your https://your.domain/.well-known/matrix/client file. This is a JSON file that clients look to for configuration information.

[dolphinscorp]

Hi Thank you very much, yesterday I tried to find this .well-known directory and client file, Matrix Server. But could not find it on matrix server. Also could not find it in element-web (root directory)

Can you please let me know where is that client json file, exact linux path please?

[grantm]

Can you please let me know where is that client json file, exact linux path please?

You might not have one currently - it's optional. If you look in the browser devtools network tab when loading your web client, you might see a request for the file and a 404 response.

One possible implementation is to simply put a static file on the web server for the domain used in your matrix user ids. So for example, if someone fires up a web client (e.g.: https://app.element.io/) and says their matrix user is @myuser:example.com, then the client will attempt to request the URL https://example.com/.well-known/matrix/client and that file (if it exists) would typically include the address of the matrix homeserver for the domain, as well as client settings. Clients may not be able to access the file if it's not served up with appropriate CORS headers.

More information at: https://spec.matrix.org/v1.3/client-server-api/#well-known-uri

We've already strayed far beyond the bounds of what's reasonable within an issue thread. You're now asking questions that would be better addressed in a support forum like: https://matrix.to/#/#synapse:matrix.org