element-hq / element-hq/element-web
Ability to reliably and timely delete a (redacted?) message from a device
- Dominant language
- TypeScript
- Stars
- 13.5k
- Forks
- 2.8k
- PR merge metrics
- PR metrics pending
Description
#### Is your suggestion related to a problem? Please describe.
In some scenarios, a user might want to ensure that a local copy of a message is deleted from their device and can thus no longer be retrieved from this device should it fall into an adversary's hands. An example of this is an activist wishing to avoid trouble with some authority.
We currently have redactions, which partially satisfy this use case. It seems that redactions are naturally tied to it, because any method of deleting messages locally without an accompanying redaction would allow the client to re-fetch the message later on (for example, when doing backfilling).
Even though redactions are best-effort, because you cannot force other users' devices to expunge a redacted message, it *would* be possible to guarantee that a redaction is honoured by all of the *redaction sender's devices*. This is one way of fully supporting the use case described in this issue.
Indeed, it seems that Element Web already does this in unencrypted rooms: after a redaction is received, the message's content is immediately replaced with an empty `content` dict and the message is no longer available on that device. (potential caveat: this might not be a hard guarantee, i.e. perhaps the message might still be available in memory until garbage collected?)
However in encrypted rooms the original ciphertext of a redacted message is still visible under View Source > Original event source even after a redaction is processed. This is a problem because an adversary which comes into the possession of a device would also have its keys and would be able to retrieve the original message content.
#### Describe the solution you'd like.
A user should be able to ensure that a redacted message is gone from their device. Note that this is only tied to redactions because otherwise a message would just be re-fetched. This is *not* about trying to force the devices of *other* users to drop a message, because that is impossible.
When processing redactions, we currently drop the decrypted event `content` dict. The proposed solution here is to also drop the `content` dict of the related `m.room.encrypted` event at the same time.
#### Describe alternatives you've considered.
Perhaps this warrants a feature separate from redactions, though I'm not sure how that would look like and would need design. Otherwise, perhaps we decide that this isn't a use case we want to support.
Contributor guide
Assessment
This issue has not been assessed yet.