-
Notifications
You must be signed in to change notification settings - Fork 14
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
Invisible Crypto: Rust for EX: display a warning when an *unverified* user changes identity #2526
Comments
@BillCarsonFr notes there is something at the store level - maybe |
Implementation: I had a chat with @stefanceriu and he said he'd like to see this information in a
So if we update Additionally, we need to expose a method to "re-pin" this identity (i.e. dismiss the warning). There is already such a method on the identity structs in the Rust crypto layer, but we would need to expose this to the higher levels. @poljar if you were able to review the above and comment on whether it is sane that would be very helpful. |
Sorry, I missed the ping initially.
This should happen for every room the member is in? Presumably we're only interested in this information when a room is actually open?
This sounds expensive and you need to watch out for races, i.e. multiple things might want to update the I think that this needs a new concept and it doesn't really belong into the |
Followup to #2492. Part of #2491, itself part of Invisible crypto.
When an unverified user changes their identity, we need to make our user aware of this. In the long term, the intention is just to show a notice in the timeline (#2493); however, that is difficult to implement and we need a stop-gap.
This task is for matrix-sdk-ui, to support #2525 and #2524 .
We think the best way to do this will be to allow listening for pin violation events on a room.
We think there may already be some kind of event when an identity changes, but we need to make sure you can listen on a room for identity changes of members of that room.
These pin violations will be triggered by a /keys/query response - either because some other person's identity changed, or because our own did.
Additionally, we need to make sure there is a suitable API to call when the user clicks "OK" - something like OtherUserIdentity::pin_new_identity exists, but we need to make sure it will work.
Later update: this is currently implemented by providing a stream of changes to users' identities, but in retrospect we think (thanks @BillCarsonFr for the suggestion) that it would be better to manage the set of all violating users either by returning all violating users in each update (which would mean the UI does not need to store any state, but might send a lot of data in rooms where something bad has happened so lots of identities are violating) or returning a delta to the set of all violating users. If/when we get a chance, we should consider changing to this approach.
The text was updated successfully, but these errors were encountered: