E2ee disabled but user is asked to setup

[theslash]

Steps to reproduce

I have a homeserver with disabled e2ee via the well-known

"io.element.e2ee": {
"force_disable": true
}

This works perfect for new users, they are not promted to setup encryption and so on.

Outcome

One user, that was there before, but not used for a long time, has no messages, no rooms etc. is always asked to setup e2ee encryption in element web.

I suspect there is something in the profile of the user I don*t know where this comes from

Operating system

Windows

Browser information

All browsers

URL for webapp

Application version

element 1.11.38

Homeserver

No response

Will you send logs?

No

[t3chguy]

The docs don't say anything about this feature making it so you don't have to set up encryption, only the following two bullets

• all rooms will be created with encryption disabled, and it will not be possible to enable encryption from room settings.
• any io.element.e2ee.default value will be disregarded.

So I'd say this is expected according to the docs

[theslash]

I'm with you in the docs, but look here:

matrix-org/matrix-react-sdk#11125

And this is how it works here since then, only for this one user it doesnt work.
The user is in no rooms, everything is completely empty, only thing i see are a few files that are left (images that he sent in old chats)
I suspect the user deleted all these chats, because I cant see any.

[theslash]

Ok now all users get the prompt to setup the keys.
Any idea what i can do to prevent this?

[theslash]

My well-known looks like this, but even with the newest elemtent-web client users are now asked to verify sessions:

location /.well-known/matrix/client {
  return 200 '{"m.homeserver": 
                {"base_url": "https://******.de"}, 
                "io.element.e2ee": 
                    {
                        "default": false, 
                        "force_disable": true, 
                        "secure_backup_required": false}
                    }';
  add_header Content-Type application/json;
  add_header "Access-Control-Allow-Origin" *;
}

[theslash]

Ok, perhaps I have a problem with the well-known.

From my homeserver.yaml:
public_baseurl: https://chat.server.de:8008/

On this URL i get the
"It works! Synapse is running"

From my config.yaml for element:

"default_server_config": {
    "m.homeserver": {
        "base_url": "https://chat.server.de:8008/",
        "server_name": "chat.server.de"
    },

My well-known is here:
https://chat.server.de/.well-known/matrix/client

could this be the problem? can i somehow check of the right well-known is used?

In the homeserver.yaml i have this code:

extra_well_known_client_content:
"io.element.e2ee": {
"default": false
}

[theslash]

Ok, another small update from me.
I found one user who doesnt get the promt to setup encyrption. i cant see why though.

Any idea how to proceed?

//Edit:
well-known seems to be ok. the browser toosl see this coming:

{"m.homeserver": {"base_url": "https://server.chat.de"}, "io.element.e2ee": {"default": false, "force_disable": true, "secure_backup_required": false}}

[tgurr]

We also started to see this for any user logging in or out and back in, which is highly unwanted in our environment as we don't want to bother users with something they don't understand (setting up encryption) hence we also disable e2ee by default to have it opt-in. Now recently element started to behave like this:

User logs in the first time and is greeted with a small popup which he can dismiss:

When the user logs in consecutivly he is now greeted with two fullscreen dialogs before even being able to reach the regular chat interface where the first one doesn't even have a dismiss button but the message has to be dismissed by clicking the X:

Then follows the second dialog:

Please give us an option to be able to turn this behaviour off.

[theslash]

@tgurr
I was able to resolve this by myself. Don't know if its a good solution, but I didn't get any responses here:

I Shutdown the synapse Server, opened the Database with a Database explorer and cleared the tables connected with e2ee, there were keys stored for the users who got this error.
First tried it with two users, then logged everyone out, removed all devices with synapse-admin and cleared these tables:

started the synapse server back up and all was good again.
Please create a copy of your db before altering it.

My bet is: This occurs when users don't properly log out, I had a few users with >50 devices registered, but I have no proof of this.

There would be a session_lifetime setting in the synapse server but its completely useless because it also logs out active users.
hope I could help

[tftm]

Dirty hack to block key generation forever.
You need to stop synapse server, connect to the synapse pgsql database and run

create function do_not_change()
  returns trigger
as
$$
begin
return null;
end;
$$
language plpgsql;

create trigger no_change_trigger
  before insert or update or delete on "e2e_cross_signing_keys"
  for each row
  execute procedure do_not_change();

create trigger no_change_trigger
  before insert or update or delete on "e2e_cross_signing_signatures"
  for each row  
  execute procedure do_not_change();

create trigger no_change_trigger
  before insert or update or delete on "e2e_device_keys_json"
  for each row
  execute procedure do_not_change();

than start synapse server again.

[richvdh]

I'm thoroughly confused about what this issue is asking for. According to the second comment, it's expected behaviour.

I'm going to go ahead and close it. Suggest opening new issues with clearer descriptions if people think there are still bugs