Manual Device Verification (eyeballing the key) doesn't work in ER

[ara4n]

Steps to reproduce

1. Log in on a new device
2. Don't verify it (e.g. because it doesn't implement verification on its side)
3. Go to your user in EWR to check the untrusted device
4. Manually verify it by comparing fingerprint
5. Discover nothing happens when clicking manual verification.

Outcome

What did you expect?

You should get a prompt to compare fingerprint, and hit 'yes' if they match.

What happened instead?

Nothing; the button ignores the presses. Nothing in the JS console either.

Operating system

No response

Application version

Element Nightly version: 2024031801 Crypto version: Rust SDK 0.7.0 (b1918e9), Vodozemac 0.5.1

How did you install the app?

No response

Homeserver

No response

Will you send logs?

No

[richvdh]

I'm not sure this is a thing we want to expose: it sounds very much like a dev tool to me. So I think the action here is to remove it from the UI

[BasilYes]

I'm not sure this is a thing we want to expose: it sounds very much like a dev tool to me. So I think the action here is to remove it from the UI

Without this I can't verify maubot, may be this feature can be hidden somewhere? Or you it's must be done on maubot side?

[KsmoinO]

In addition to the information given in #27497, I would also like to point out that I use a version 6 key backup.

[JuniorJPDJ]

still an issue

[foresto]

This is a real problem if you're trying to use or develop a simple client that will never have the more complex verification methods.

For example, I have a lightweight unread message notifier with nearly zero dependencies and no UI of its own. Its sessions have device keys, but no crypto beyond that. Element was the only way of verifying them, and that's now broken. Using it anyway would trigger alerts and brand the account with red badges of shame, which is no good for anyone, so AFAICT, it's effectively shut out of the ecosystem because of this bug.

I see several other reports have already been filed (now marked as dupes), but just in case it helps, here's what appears on the firefox console when I click the (unresponsive) Verify Session button:

Uncaught Error: End-to-end encryption disabled
    checkKeyBackup client.ts:3324
    setDeviceVerified client.ts:2439
    o UntrustedDeviceDialog.tsx:77
    d QuestionDialog.tsx:42
    React 11
    unstable_runWithPriority scheduler.production.min.js:17
    React 3
client.ts:3324:12
Uncaught (in promise) Error: End-to-end encryption disabled
    setDeviceVerification client.ts:2490
    setDeviceVerified client.ts:2433
    o UntrustedDeviceDialog.tsx:77
    d QuestionDialog.tsx:42
    React 11
    unstable_runWithPriority scheduler.production.min.js:17
    React 3
client.ts:2490:12

[jadedeane]

This is a real problem if you're trying to use or develop a simple client that will never have the more complex verification methods.

For example, I have a lightweight unread message notifier with nearly zero dependencies and no UI of its own. Its sessions have device keys, but no crypto beyond that. Element was the only way of verifying them, and that's now broken. Using it anyway would trigger alerts and brand the account with red badges of shame, which is no good for anyone, so AFAICT, it's effectively shut out of the ecosystem because of this bug.

I see several other reports have already been filed (now marked as dupes), but just in case it helps, here's what appears on the firefox console when I click the (unresponsive) Verify Session button:

Uncaught Error: End-to-end encryption disabled
    checkKeyBackup client.ts:3324
    setDeviceVerified client.ts:2439
    o UntrustedDeviceDialog.tsx:77
    d QuestionDialog.tsx:42
    React 11
    unstable_runWithPriority scheduler.production.min.js:17
    React 3
client.ts:3324:12
Uncaught (in promise) Error: End-to-end encryption disabled
    setDeviceVerification client.ts:2490
    setDeviceVerified client.ts:2433
    o UntrustedDeviceDialog.tsx:77
    d QuestionDialog.tsx:42
    React 11
    unstable_runWithPriority scheduler.production.min.js:17
    React 3
client.ts:2490:12

Yup, see this.

[chagai95]

I just sent logs, some clients are very buggy and this is a really important feature imho, it makes everything everywhere red, which means that in really annoys everyone...

[MRAAGH]

@chagai95 I found a workaround: log in in an older version of Element and verify it via any method. And then you will be able to use text verification from there. For security reasons, I recommend logging out from old Element immediately after you're done.

@foresto if you need a quick verification for testing, I put up Element v1.11.19 at https://element.mazie.rocks/oldversion - but for a private account you should use a trusted source, not from random person on the internet ^^

[foresto]

Thanks for thinking of me. I tried an older Element Desktop build, but it was missing this feature, too. I guess 1.11.33 isn't old enough, but I didn't want to go older, due to security concerns.

Anyway, I no longer need it. In the months since my last comment, I gave up on Element, worked my way through some confusingly worded parts of the spec, and built my own tool for verifying Matrix devices by fingerprint.

Not everyone has the time or skills to do that, though, and device signing is not just a dev tool. As things stand now, anyone who needs their communication service to support automation will find Matrix lacking, for the rather silly reason that the official client removed the ability to verify automation clients. For the community's sake, I hope this regression will be fixed.

[chagai95]

Thx for thinking of me too, already did that but it kind of didn't work on some clients, it's very weird. Anyway check out riots.im

[foresto]

The problem here is not fixed. People still need a way to verify their bots and other non-interactive clients.

[t3chguy]

I suggest making a suggestion to the https://github.com/matrix-org/matrix-rust-sdk-crypto-wasm project to support such a thing in that case, though that won't mean the Element product team wants that feature in its UX, that'd be up to the Product team if the technical problem was lifted.

[foresto]

This is a disappointing response from the official officially-recommended Matrix application. Previously, non-interactive apps were supported by a feature in the reference client. The maintainers broke it, then ignored reports of the lost functionality, and have now discarded it entirely with no alternative provided.

This demonstrates to community developers that tools provided by Matrix maintainers/adjuncts might disappear at any time, and shows users that depending on the Matrix ecosystem for their communications is something of a gamble. It also rather undermines any claim that Matrix has good support for bots and moderation/admin tools.

If the feature needs to be moved, that's understandable, but I would have expected the custodians of a released feature that people were using to work with the related development teams to have it adopted elsewhere. Just dropping it on the floor and telling affected users to deal with it themselves is an unpleasant surprise that doesn't exactly boost one's confidence in Matrix.

[t3chguy]

This is a disappointing response from an official Matrix project.

Element Web/Desktop isn't an official Matrix project. Element is a project built on Matrix made by the same people which started Matrix way back when, but Matrix is its own entity and is not controlled by Element or vice versa.

[steadfasterX]

so as far as I understood there is a feature which was working fine before which is still present in the web UI and desktop client (Element version: 1.11.86
Crypto version: Rust SDK 0.7.2 (517d99b), Vodozemac 0.7.0) and which is not working anymore.

To clarify @t3chguy is this a bug in the mentioned rust project which broke the functionality in element or what happened? I am happy to provide any logs or open new issues wherever needed to get this functionality back..

[t3chguy]

Its a case of the crypto team along with product choosing to not bring that feature over to the rust crypto stack in matrix-js-sdk, apparently it is supported in the linked rust project.

[MRAAGH]

in the end, not every program needs every feature. But that's the magic of open source and open standards - if we don't like Element, we can use a different client

[t3chguy]

or even fork it