element-hq / element-hq/element-web
regression: failure to recognize a verified device if it has an empty device_keys.algorithms array
- Dominant language
- TypeScript
- Stars
- 13.5k
- Forks
- 2.8k
- PR merge metrics
- PR metrics pending
Description
### Steps to reproduce
Recent versions of Element Web are reporting a device with correctly signed keys as unverified, if its `device_keys.algorithms` array happens to be empty.
This regression was apparently introduced some time after v1.11.92. That version (and every earlier version I tried) recognizes such devices as verified.
### Outcome
#### What did you expect?
I expected newer versions of Element Web to recognize that the device's keys are uploaded, consistent, and properly signed, and therefore display it as a verified device. Just as Element Android and earlier versions of Element Web do.
#### What happened instead?
Recent Element Web versions fail to recognize the device as verified.
#### Why is this a bug?
Because clients exist that do not participate in message encryption/decryption, but still need to log in on the user's behalf in order to do their job. (For example, an unread message indicator like [messageflag](https://codeberg.org/forestix/messageflag).) In order to avoid annoying the user with "verify your device" warnings and scaring their contacts with red shield icons, these devices must show up as verified.
The spec says the `algorithms` field is required, but does not forbid it from being empty. This makes sense, for the reason stated above (some clients will never support message decryption).
https://spec.matrix.org/v1.15/client-server-api/#post_matrixclientv3keysupload
Common chat clients generally populate the `algorithims` array with two values: `m.olm.v1.curve25519-aes-sha2` and `m.megolm.v1.aes-sha2`. Adding one or both of these to the array (and signing the device keys) sort of works around the problem, in that it convinces Element Web to display the device correctly. However, neither of these is suitable for a client of the kind described here, because those values indicate support for Olm and Megolm encryption, which clients like this do not support.
https://spec.matrix.org/v1.15/client-server-api/#molmv1curve25519-aes-sha2
https://spec.matrix.org/v1.15/client-server-api/#mmegolmv1aes-sha2
Adding a nonsense value like `foo` to the array works around the problem as well, demonstrating that these newer Element Web versions are complaining about something that they clearly don't need.
So, I think this regression is clearly a bug.
### Operating system
_No response_
### Browser information
_No response_
### URL for webapp
_No response_
### Application version
Element version: 1.11.110, Crypto version: Rust SDK 0.13.0 (f64839e), Vodozemac 0.9.0
### Homeserver
matrix.org
### Will you send logs?
No
Contributor guide
Assessment
This issue has not been assessed yet.