E2E Device lists can get out of sync with the devices actually present in a room.

[ara4n]

Device lists can get out of sync for various reasons:

• Still seeing devices which have been deleted element-web#4527
• Dummy issue synapse#8631
• Synapse doesn't send out device list updates to previously unseen homeservers when joining a room synapse#11374
• Invited users don't trigger device_list updates via /sync at the point of being invited. synapse#3503
• Invited users don't trigger device_list updates when their device lists change. synapse#3504
• Users whose servers were unreachable when you logged in will send you undecryptable messages #2314
• Device list not updated on sending device, leading to UTDs #2594

---

@richvdh mentioned in #e2e-dev the other day that he'd had some thoughts on how to address these:

<Matthew> richvdh: so, you think we should make devicelists a best effort thing
<Matthew> and if A sends to B and B’s server sees B has added devices (whether B is invited or joined)
<Matthew> then B’s server should tell A, “actually, encrypt for more devices plz”
<Matthew> and you hope that turnaround happens fast enough that A is still there and will then handle whatever verification is needed to do so?
<richvdh> yup
<richvdh> you would probably apply more intelligence, so that A can choose not to send to certain of B's devices
<richvdh> so, alongside the message, A would say "I'm targeting generation # 123 of B's device list", and B's server would compare the generation number rather than the actual target devices

However, this doesn't help solve the issue on element-hq/element-web#2713 (comment) where the messages would only be sent to the invited user after they joined the room (at which point it's too late for the sender to re-encrypt them for missing devices). I wonder if a solution could be to support subscribing to arbitrary user devices using simple pubsub semantics: Alice can subscribe to updates about Bob's device list (using an API which hopefully is resilient to unreliable connectivity between Alice & Bob's HSes). Updates could only be allowed if Alice can 'see' Bob (i.e. if Alice has invited Bob or shares a room with him), although this is a pretty weak security mechanism given anyone can invite anyone (although at least Bob would know that Alice was stalking him).

I've opened this issue to track the idea of rethinking how devicelists work (again) before they get baked into the spec.

[ara4n]

an alternative could be to just store and relay device lists as a room (as well as other per-user profile info, presence lists, etc).

[kegsay]

rethinking how devicelists work (again) before they get baked into the spec.

was this ever addressed before it landed in the spec?

[williamkray]

i regularly have users that cannot decrypt messages from specific other users in encrypted rooms. the fix is often to use /discardsession or part/rejoin the room. is this related? is this the issue they should be sending their rageshake logs to? i've been struggling for the last year or so to tell them what to do about this and nobody has had any answers, but this seems to align with the behavior i'm seeing. if i can at least point them to an issue to connect their logs to, they might feel more enabled to actually send those logs.

[turt2live]

Related: element-hq/element-web#3846

[richvdh]

rethinking how devicelists work (again) before they get baked into the spec.

was this ever addressed before it landed in the spec?

it was not.

[richvdh]

so, alongside the message, A would say "I'm targeting generation # 123 of B's device list", and B's server would compare the generation number rather than the actual target devices

This continues to be the sort of thing I'm thinking about to fix this. I'm not quite sure what the mechanism would be for transmitting that extra metadata alongside the message: in a large room including a device-list generation for each user could be a very large amount of data.

[dkasak]

A would say "I'm targeting generation # 123 of B's device list"

I guess I'm failing to follow a bit. What exactly would be the expected effect or outcome of A sending this metadata?

[richvdh]

A would say "I'm targeting generation # 123 of B's device list"

I guess I'm failing to follow a bit. What exactly would be the expected effect or outcome of A sending this metadata?

The idea is something along the lines of: If, by the time the message reaches B's server (or maybe even one of B's devices), the device list is now at generation # 124, it would send a notification back to A, who would re-fetch the device list and try again.

[richvdh]

However, this doesn't help solve the issue on element-hq/element-web#2713 (comment) where the messages would only be sent to the invited user after they joined the room (at which point it's too late for the sender to re-encrypt them for missing devices)

I don't understand this. What does it mean "messages would only be sent to the invited user after they joined the room" ?

Anyone any idea?

[kegsay]

The issue in the linked comment is talking about the scenario where Alice invites Bob to a room, says something in the room (so we encrypt for Bob's devices) but then a new device for Bob logs in, and Alice doesn't know about the new device so doesn't encrypt for it. This is mitigated by key backups because Bob's original device will be uploading keys to the backup which the new device can read.

In this context, the sentence "messages would only be sent to the invited user after they joined the room" effectively means messages would only be sent to the new device after they joined the room, which I think is what he is trying to say?

[richvdh]

Oh right. Well, we can discuss that further on element-hq/synapse#3504 rather than trying to use this epic issue for it.