-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sender key distribution unreliable when running in embedded mode #2415
Comments
Thanks for the detailed report! I think it is clear from your comment that you are talking about the first case, but can you confirm:
|
maybe matrix-org/matrix-js-sdk#4198 is related |
Yes, this is the case. |
I have been able to find one reproducible issue:
In this video device A is on the left and device B is on the right: Missing.key.after.failure.to.join.mov(n.b. device A is running a customised version which shows decryption errors across the top of the media) |
This can be updated to now be reliable in EW but not in EC SPA right? |
I locally reverted the fix for #2458 and re-tested to see what the cause of the lost encryption key was. Adding commentary to the reproduction steps I see:
During this device A sends a
Device B sends a
Device A starts EC again which sends a new However, when device B receives the state event update from A it sees that the memberships/participants haven't changed and so does not rotate its encryption key or resend the encryption key.
Because device B doesn't send another Some initial thoughts on how this could be addressed:
|
During discussion today with @toger5 it became clear that a similar case could also happen with EC running in SPA mode with per participant keys. Specifically, in SPA mode EC doesn't attempt to fetch encryption keys from room history and assumes that it will receive them all after it joins. A hypothetical (unvalidated) scenario would be: device A is using SPA on a call; the user reloads the SPA browser tab; device A reconnects but doesn't have any encryption keys; the other participants (e.g. device B) don't think that the participants have changed (so no rotation) nor do they resend their keys. What this suggests is that we should address this behaviour even though #2458 is in place. In choosing an approach we should be mindful that we expect the distribution of encryption keys to be migrated to to-device messages. It feels unlikely that it makes sense for a Matrix client to allow for previous to-device messages to be searched and processed. As such, this suggests that the third (have the devices pro-actively resend their keys) or fourth (allow a device to request the resend) approaches are most suitable. |
During the meeting I forgot to mention that we basically have a "request key" mechanism in place. (Really good we tackle this now since reliable call memberships would have made this even more hidden. If users take more then 5s to reload and go through the lobby this issue would not occur. Whcih is also a "almost" fix but I think the logic: on call initialization, check if the server state thinks you are already connected and if so disconnect and reconnect since you abviously just started up the connection with this device -> should be in not connected state. Sounds like sth we should do anyways) |
This feels like an elegant approach but I think it will have unintended consequences such as in embedded mode Element Web will think that the call has ended and terminate the iframe containing Element Call. Instead I have made matrix-org/matrix-js-sdk#4343 which will cause a resend of the current encryption keys if the |
This will need a js-sdk bump once matrix-org/matrix-js-sdk#4343 is merged. |
Needs js-sdk bump. |
Bump was done in #2567 |
When running as a widget (embedded mode) within Element X and Element Web, there have been reports of participant sender keys not finding their way to other recipients. This has resulted in those recipients not able to decrypt the media and so shows a grey box instead.
Apparently it is intermittent. This could be in the widget API interface or somewhere else. The keys are distributed via encrypted room events.
Whilst there is discussion about moving key distribution to use to-device messaging instead of encrypted room events for other reasons, it is not known if the root cause of the problem would also affect an alternative implementation
Possible next steps:
The text was updated successfully, but these errors were encountered: