search

element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
72 stars 12 forks source link

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

Open ara4n opened 6 years ago

ara4n commented 6 years ago

Device lists can get out of sync for various reasons:

@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 https://github.com/vector-im/riot-web/issues/2713#issuecomment-402989021 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 commented 6 years ago

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 commented 4 years ago

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

was this ever addressed before it landed in the spec?

williamkray commented 2 years ago

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 commented 2 years ago

Related: https://github.com/vector-im/element-web/issues/3846

richvdh commented 11 months ago

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 commented 8 months ago
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 commented 8 months ago

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 commented 8 months ago

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 commented 5 months ago

However, this doesn't help solve the issue on https://github.com/element-hq/element-web/issues/2713#issuecomment-402989021 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 commented 4 months ago

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 commented 4 months ago

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