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