-
Notifications
You must be signed in to change notification settings - Fork 382
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
MSC2399: Reporting that decryption keys are withheld #2399
Conversation
this is looking very good to me, fwiw |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems sane
This has been implemented and seems to be working. |
@mscbot fcp merge |
Team member @uhoreg has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
@cloudyfuel I'm confused by what you're saying.
This is what the proposal is. The Alice's device is sending a message saying that it is purposely not sending keys to Bob.
This is what is done without this proposal. The generic message is "The sender's device has not sent us the keys for this message." in Riot Web.
It's not leaked to random third parties. It's sent as a to-device message, so only the users and their homeserver admins can see it. Also, "lost their key"?
That is not what the proposal it doing.
Huh? I don't understand what this has to do with the proposal.
In practice, it has helped debug some cases of unintentional unable-to-decrypt errors by pointing to the exact cause of the issue (e.g. the sender had turned on the option to only send to verified devices without meaning to). It also indicates to the user that they should not expect to be able to read the message, so they don't have to wonder if they'll ever be able to.
The current implementation in Riot sends them unencrypted, but they could be encrypted if needed. But I don't really see it as particularly sensitive information. The messages are optional in any event, so if you're worried about leaking the data, you could simply not send it. |
Added a section about key sharing. |
user was not in the room when the message was sent | ||
- `m.unavailable`: sent in reply to a key request if the device that the key | ||
is requested from does not have the requested key | ||
- `m.no_olm`: an olm session could not be established. This may happen, for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have gone with something slightly more generic here, since the problem is a failure to create a peer to peer encrypted channel rather than anything specific to olm (one day people might use another mechanism). Not a strong opinion though.
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
Spec PR: #2826 |
Merged 🎉 |
Rendered