MSC2399: Reporting that decryption keys are withheld #2399
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.
I think I have a better solution.
Instead of Bob being responsible for telling Alice that Alice's device doesn't send keys, the Alice's device - the root of the problem - should be responsible for this. Bob should be shown a generic status event like 'Alice didn't send you the key, this may be because she didn't verify you, blacklisted you' or no message at all on the corresponding device.
Why leak verification status, blacklisting status or if the user lost their key to random third parties the user most likely doesn't wish to communicate with? Why rely on an entity completely out of your control to tell you there's something wrong with your device? Why hide the fact that someone is probing me for keys? Seems intuitive that I should know if someone is contacting me instead of them knowing that and additionally a bunch of metadata about my setup.
Separately from this, if there's a real need for communicating that to random parties, the device could communicate that. But that makes sense only for communicating errors and only when this can point the sender to fixing the problem (rather than saying: oh there's an error, but you can't do anything about it lol).
Edit: AFAIU the key withheld events are also unencrypted, so they leak metadata to the server too. This is at least as bad and can be mitigate similarly by simply informing the user about these problems rather than needlessly sending that info to whoever via the server.
@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.