Device list tracking does not handle users who leave rooms

[richvdh]

Suppose:

• We share an encrypted room with Bob
• Bob leaves that room
• Bob signs in on a new device
• Bob rejoins the room
• We send an encrypted message

In this case, Bob's new device will see a UISI, because we will not encrypt for it.

The problem is that there is no way to mark Bob as 'untracked', so we think we have an up-to-date list of Bob's devices, where we do not.

I think this is related to #1191.

[poljar]

Interesting, I would have assumed that the server will tell us that Bob has changed at the same time we receive the m.room.member event that inserts Bob back into the room.

Why can't it do so?

[cvwright]

Isn't it also a problem that the crypto crate never learned about Bob leaving in the first place?

When somebody leaves (or is kicked/banned), don't you typically want to start a new chain of keys that the left user doesn't know?

[richvdh]

I need to investigate this a bit more to figure out exactly what happens, but to do that first I need to fix element-hq/element-web#24795.

[richvdh]

When somebody leaves (or is kicked/banned), don't you typically want to start a new chain of keys that the left user doesn't know?

Yes, but the decision of which users to encrypt for is left to the application (share_room_key takes a list of users), so that bit works ok.

[richvdh]

Interesting, I would have assumed that the server will tell us that Bob has changed at the same time we receive the m.room.member event that inserts Bob back into the room.

Indeed, it turns out this is exactly what happens. As the spec says (my emphasis).

changed: List of users who have updated their device identity or cross-signing keys, or who now share an encrypted room with the client since the previous sync response.

So, this is a non-issue. Sorry for the noise!

[richvdh]

Related: here's where we originally fixed this for the js-sdk back in the day - by adding the user to changed: element-hq/element-web#4983