4 ms·

>> 9. the end-to-end encryption is also annoyingly fragile >Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages t

>> 9. the end-to-end encryption is also annoyingly fragile >Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it. You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys. This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed. The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.

cyphar 1y ago
Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never seen anyone opt-in to "don't send to untrusted devices" because even with device signing, it breaks usability in most group chats). Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues. Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.
- AstralStorm 1y ago
  Adding fake devices doesn't do anything since the homeserver doesn't have your key. It literally can't do that. If you're sending encrypted to untrusted on a public room, you're trusting the homeserver. It's literally like trusting a web server that it won't MITM you.
  - cyphar 1y ago
    If a homeserver adds a fake device to an existing user of a room, the default behaviour of Matrix clients is to implicitly trust that device and send new messages to it. So any homeserver used by any user in a room could read future messages transparently and without any indication to the user that this is happening (unless all users in the room have opted-in to the "do not send to untrusted devices" knob). This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
    - Arathorn 1y ago
      Ugh, yes - i'd made the mental leap that https://github.com/element-hq/element-meta/issues/2700 https://github.com/element-hq/element-meta/issues/2700 had finished rolling out, whereas it looks like it's now delayed until October due to having to wait for the ecosystem to catch up. my bad.
      - cyphar 1y ago
        To be clear -- I am very glad that this issue is finally being resolved after such a long time. I just wish that there had been a larger warning about it from the start (especially once E2EE stopped being marked as experimental).
- Arathorn 1y ago
  I’ve never said this is “only an issue for malicious homeservers”. I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
  - cyphar 1y ago
    And you need to opt-in to the global-and-off-by-default "don't send to unverified devices" setting, right? Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)
simonmic 1y ago
Sounds frustrating. Report it for investigation, please.
Arathorn 1y ago
Okay - as I said in the parent, this should not happen. Most people report UTDs as having gone away; i haven’t seen any myself in months, let alone any this bad. The only scenario i can think of here is either you logged out of all devices on your account (so nobody could encrypt for you as you didn’t exist any more) or the room is impressively corrupt (state resets) or the server is impressively buggy (eg a beta) or the servers can’t actually talk to each other (eg messages are being replicated transitively but keys aren’t). Please can you report with details so we can actually investigate? As per the linked conference talks, we went on a gigantic mission to fix this, which based on our telemetry was successful.

cyphar 1y ago

Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never seen anyone opt-in to "don't send to untrusted devices" because even with device signing, it breaks usability in most group chats). Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues. Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.

AstralStorm 1y ago
Adding fake devices doesn't do anything since the homeserver doesn't have your key. It literally can't do that. If you're sending encrypted to untrusted on a public room, you're trusting the homeserver. It's literally like trusting a web server that it won't MITM you.
- cyphar 1y ago
  If a homeserver adds a fake device to an existing user of a room, the default behaviour of Matrix clients is to implicitly trust that device and send new messages to it. So any homeserver used by any user in a room could read future messages transparently and without any indication to the user that this is happening (unless all users in the room have opted-in to the "do not send to untrusted devices" knob). This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
  - Arathorn 1y ago
    Ugh, yes - i'd made the mental leap that https://github.com/element-hq/element-meta/issues/2700 https://github.com/element-hq/element-meta/issues/2700 had finished rolling out, whereas it looks like it's now delayed until October due to having to wait for the ecosystem to catch up. my bad.
    - cyphar 1y ago
      To be clear -- I am very glad that this issue is finally being resolved after such a long time. I just wish that there had been a larger warning about it from the start (especially once E2EE stopped being marked as experimental).
Arathorn 1y ago
I’ve never said this is “only an issue for malicious homeservers”. I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
- cyphar 1y ago
  And you need to opt-in to the global-and-off-by-default "don't send to unverified devices" setting, right? Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)

simonmic 1y ago

Sounds frustrating. Report it for investigation, please.

Arathorn 1y ago

Okay - as I said in the parent, this should not happen. Most people report UTDs as having gone away; i haven’t seen any myself in months, let alone any this bad. The only scenario i can think of here is either you logged out of all devices on your account (so nobody could encrypt for you as you didn’t exist any more) or the room is impressively corrupt (state resets) or the server is impressively buggy (eg a beta) or the servers can’t actually talk to each other (eg messages are being replicated transitively but keys aren’t). Please can you report with details so we can actually investigate? As per the linked conference talks, we went on a gigantic mission to fix this, which based on our telemetry was successful.