secure_backup_required in .well-known/matrix/client has no effect

[rltas]

Steps to reproduce

My https://mydomain.net/.well-known/matrix/client:

{
    "im.vector.riot.e2ee": {
        "default": false
    },
    "io.element.e2ee": {
        "default": false,
        "secure_backup_required": true,
        "secure_backup_setup_methods": ["passphrase"]
    },
    "m.homeserver": {
        "base_url": "https://matrix.mydomain.net"
    },
    "org.matrix.msc3575.proxy": {
        "url": "https://matrix.mydomain.net/sliding-sync"
    }
}

I know it's generally working because the default encryption setting is honored.
Update: my colleague just said this works in Element on iOS, but not in Element Web.

Outcome

What did you expect?

That I can use Element only after setting up secure backup as per the docs.

What happened instead?

No visible change.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

Element version 1.11.38, Olm version 3.2.14

Homeserver

Synapse version 1.89.0

Will you send logs?

No

[t3chguy]

Will you send logs?
No

Please send logs

[rltas]

Will you send logs?
No

Please send logs

Of what exactly?

[t3chguy]

Of the app

[rltas]

Dunno why I thought this was meant for something different - just sent it.

[t3chguy]

secure_backup_required is false in your deployment, also be careful you serve the file in 2 places.

bXX-XXXt.XX-XX.net & matrix.bXX-XXXt.XX-XX.net - the former is the only valid as per https://spec.matrix.org/v1.8/client-server-api/#well-known-uri

I suggest retrying once you ensure the former URL has secure_backup_required=true

[rltas]

Yeah I noticed that too, that seems to be some quirk with the ansible playbook but it's the same file being served under both urls. I changed the setting back after submitting the report, that's why it was false - I can keep it true and give you a test user if that helps.

What I just figured out:

• upon first logging in with a fresh user, no backup is enforced
• when logging in and skipping verification, no backup is enforced
• when logging in and resetting keys, backup is enforced
• when hitting F5 at that point, no backup is enforced

Is that behaviour intentional? Eventually it's how it's meant to work, but if so it's unintuitive as I can manually configure a backup anytime, starting with a fresh user, and that seemingly arbitrary flow makes it harder to on-ramp users with a step-by-step guide.

/e: I assume that behaviour is not intentional as I can as well just cancel the backup setup and move on, which isn't in line with what the setting is meant to achieve according the docs ("Setup that backup now or you're going nowhere").

[richvdh]

seems like this was a config error