Unable to deploy .well-known file to disable E2EE by default. Consider config.json alternative

[tgurr]

Description

Trying to implement #13914 I run into an issue.

I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:

{"m.homeserver": {"base_url": "https://matrix.corporate.local/"}, "m.identity_server": {"base_url": "https://matrix.corporate.local"}, "im.vector.riot.e2ee": {"default": false}}

and also in config.json of riot

    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.corporate.local",
            "server_name": "Corporate Local"
        },
        "m.identity_server": {
            "base_url": "https://matrix.corporate.local"
        },
        "im.vector.riot.e2ee": {
            "default": false
        }

Now my question is if that isn't enough and if not if we could please have the option to specify this via config.json of riot as well since that doesn't seem to work right now(?).

Because our synapse is running on matrix.corporate.local in a corporate environment where corporate.local points to the active directory servers on which I can't and also don't want to run a webserver to just serve a .well-known for the domain.

Steps to reproduce

• Have a setup like described above
• Try to implement Add e2ee-default:false docs #13914
• See Riot still creating DMs and rooms with encryption enabled by default

Version information

• Platform: web (in-browser)

For the web app:

• Browser: Chrome, Firefox latest versions
• OS: Windows, Linux
• URL: self hosted, latest riot web 1.6.6-rc.1

[t3chguy]

and also in config.json of riot

It is not a config.json option.

What do your user names look like, @bob:matrix.corporate.local? or is it just :corporate.local ?

[tgurr]

and also in config.json of riot

It is not a config.json option.

Hence my request to please add such an option.

What do your user names look like, @bob:matrix.corporate.local? or is it just :corporate.local ?

They're just :corporate.local.

[t3chguy]

Hence my request to please add such an option.

Product team specifically said well-known only

They're just :corporate.local.

Then your well-known URL is wrong;

I've added the json section in https://matrix.corporate.local/.well-known/matrix/client:

It should be

https://corporate.local/.well-known/matrix/client

[tgurr]

It should be

https://corporate.local/.well-known/matrix/client

As I explained corporate.local points to the active directory domain controllers on which I don't want and won't install an additional web server in any form. I'm pretty sure I'm not the only one with that problem.

[t3chguy]

Sorry, missed that.

Well as per the Matrix spec, that is the only place the well-known is looked up.
https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri

[tgurr]

Hence my request to please add such an option.

Product team specifically said well-known only

Well as per the Matrix spec, that is the only place the well-known is looked up.
https://matrix.org/docs/spec/client_server/r0.6.1#well-known-uri

Maybe the product team could reconsider it's decision as there obviously seem to exist use cases for that. I fail to see where having an additional configure option would hurt.

[t3chguy]

It wouldn't apply to riot-android, riotX-android, riot-ios
the well-known route was chosen for consistency between clients (not that they support it yet but still)

the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product

[tgurr]

It wouldn't apply to riot-android, riotX-android, riot-ios
the well-known route was chosen for consistency between clients (not that they support it yet but still)

the mobile clients have no equivalent of config.json so a feature-parity mismatch was chosen against by Product

Which wouldn't be a problem (in our case) as I can and have configured a proper https://corporate.local/.well-known/matrix/client reachable from the outside/internet perfectly well. We could argue how stupid it is to have the same domain internally and externally but it's how it was done and out of my control.

[jryans]

We'll track this as a suggestion for now. I would helpful to hear from other deployments that might also be in this situation of being unable to deploy .well-known so we can consider alternative options.

[t3chguy]

oops, didn't realise you already changed

[andrewhotlab]

I would helpful to hear from other deployments that might also be in this situation of being unable to deploy .well-known so we can consider alternative options.

+1 for us. Please understand that not all sysadmins out there can easily accomplish such a requirement. Since we are discussing about element-web here, it would be so far more simple to make this setting available in the config.json file.

[FlyveHest]

Does the io.element.e2ee setting do anything in the client these days?

I've been trying to get this to work, but have had no luck, client doesn't seem to retrieve .well-known file at all, and if I grep through the element-web codebase for e2ee, the only hits I get are in the docs MD files and changelog. (This may be me not understanding to source structure, but I do find it quite odd)

[t3chguy]

@FlyveHest https://github.com/matrix-org/matrix-react-sdk/blob/2c313e0c5e4cc044996c4c80fe2a287aad1b10cf/src/utils/WellKnownUtils.ts#L20
https://github.com/matrix-org/matrix-react-sdk/blob/2c313e0c5e4cc044996c4c80fe2a287aad1b10cf/src/utils/WellKnownUtils.ts#L40-L49

Yup definitely still used.

[FlyveHest]

Thanks for the super-speedy reply :) I do have a small followup question.

When does Element-web query those? Is it only done on login, or should it be every time I open the client after having closed the tab/browser?

Having my apache logs open, I get no hits on the well-known file, not even 404s

[t3chguy]

It does it at app launch and every 2h whilst running.
Are you definitely looking at the right logs?
If your Synapse is running at synapse.domain.org but your usernames are @something:domain.org then the well-known is at https://domain.org/.well-known/matrix/client

[FlyveHest]

Yes, I found that info in some other threads, users are @user:sub.domain.tld and server is running at sub.domain.tld

I'm looking at a combined log for both sub.domain.tld and domain.tld, just in case.

[t3chguy]

I suggest looking at the client's/browser's Network log instead, as that's the only one that is guaranteed, there's many things in the path of the network which could go awry.

[FlyveHest]

I can see it does find the .well-known file in the network log, and it is io.element.e2ee that is the correct key, as per https://github.com/vector-im/element-web/blob/develop/docs/e2ee.md?

Am I on the other hand wrong in understanding that it should have a visual impact in the client? Can I check somewhere that the client has gotten the key?

[t3chguy]

In the Create a private room dialog it defines the default state of the Enable end-to-end encryption checkbox
It also is used to decide whether DMs should be e2ee by default, try create a DM and see if it is automatically E2EE or not

[FlyveHest]

I can see the toggle in the Create Room (I think this was always the case, though), but direct conversations are still encrypted upon creation.

EDIT: Removed link

[t3chguy]

I can see the toggle in the Create Room

Is that toggle (e2ee) on or off by default though?
In my case (default) it is on-by-default when I switch Make this room public OFF

[FlyveHest]

On by default here as well, when I open create room.

And, there are no toggles when connecting to "People", I just get a conversation looking like this

[t3chguy]

What do you get when you run mxMatrixClientPeg.matrixClient.getClientWellKnown() in the Browser Console of a running Element?

[FlyveHest]

I get an empty object, {}

Can this be CORS related, the client is running on (EDIT: Removed link), but I can see the request for the well-known file in the network tab, and there is the expected data in the response.

[t3chguy]

Yeah if the request in the network tab is successful then I'd expect it to be in getClientWellKnown - you have stumbled upon a bug for which I have no explanation

[FlyveHest]

I think maybe my browser have this cached, if I try in another browser, I actually do get a CORS error.

Man, this one is all on me, thank you so much for your help, and sorry to have wasted your time.

Maybe I should write a bridge to chat via GitHub issue comments ;)

[remram44]

I am running into this. I can't use .well-known at the server_name, I am using SRV records and Element's config.json>default_server_config for server discovery. The spec made it seem like this was fully supported, but now I cannot set important client settings.

I have tried putting the io.element.e2ee in the default_server_config of Element, but that doesn't appear to be read.

Please move configuration options somewhere where every spec-following deployment can set them.

[t3chguy]

Please move configuration options somewhere where every spec-following deployment can set them.

What makes you spec-following distinctly vs someone who hosts a .well-known/matrix/client file? Your SRV record is entirely unrelated to this file, SRV is for server-server API discovery only, not intended for clients.

[remram44]

I did say every spec-following deployments... I am not asking you to choose...

I am not asking you to stick with using the server-discovery mechanism to publish those settings either. If it can't be done that way, maybe do it a different way, such as config.json.

[williamkray]

I have made a small attempt to update the synapse documentation to be more explicit about this particular topic, would love to get this audience's eyes on it to make sure this might help eliminate confusion in the future: matrix-org/synapse#14959