Self-destructing/disappearing messages

[ajvsol]

This is obviously not a foolproof security measure because clients can be modified to not redact previously sent messages for example, but a recent thread has given some examples on why this is a useful feature nonetheless.

[Disappearing messages] are a collaborative feature for conversations where all participants want to automate minimalist data hygiene, not for situations where your contact is your adversary — after all, if someone who receives a disappearing message really wants a record of it, they can always use another camera to take a photo of the screen before the message disappears.

https://whispersystems.org/blog/disappearing-messages/

I just had an interesting conversation with a friend who was recommending that I use Telegram/Wickr, and I told him that Signal was where it's at. Then he asked me if it had self-destructing messages, and I said "Why bother? That can be easily circumvented". His reply was that in some countries phones had been confiscated, and even though one person had enabled local encryption, the user with the confiscated phone had not enabled it; thereby implicating everyone who had communicated with that person (even though the messages were delivered secure over the network). So while self-destructing messages are in many ways a flawed guarantee of privacy, they can perform a very useful function in cases where the users are not malicious, but rather are security ignorant (i.e. most people with a phone).

https://whispersystems.discoursehosting.net/t/automatically-disappearing-messages/473/18

I've always been thinking that the critique of such a feature is based on a false underlying premise.

Yes, it's true that the recipient can make a screenshot of the message. But the recipient in the absolute majority of cases is not a "threat" in a classical sense, not someone with bad intentions or someone who is not supposed to know the contents of that message. After all, the sender trusts the recipient, as he is the one sending the message to the recipient in the first place.

The usual scenario is a recipient who is not that security-aware and doesn't think about those things that much if at all. Personally, I'd say most of my contact are that way.

The sender might send this recipient a message containing something especially critical, say, a user name and a corresponding password, and doesn't want to see that information in the wrong hands if e. g. later on, the recipient loses their phone, the phone gets stolen, etc. Also note that this kind of recipient is unlikely to use a general passphrase for Signal as this lessens convenience.

https://whispersystems.discoursehosting.net/t/automatically-disappearing-messages/473/10

I think OWS are hard at work trying to convey this as a convenience rather than as a security measure. Their explanation of why you should use it seems a bit weird, but it is at least better than claiming that you have any control over a message you send to another person.

I really think that they should frame it as a data retention measure between mutually trusting parties. In most countries deleting messages once a criminal investigation has started is a criminal offence. If you operate either in an environment where high data security is a priority or when you are at the outskirts of the law (or in a country where the law "applies arbitrarily" disfavouring opponents of the government) a clear and openly communicated data retention policy is a must.

The pirate bay guys probably wouldn't have been convicted if they had one in place.

https://www.reddit.com/r/crypto/comments/5706th/disappearing_messages_for_signal/d8ojhg2/

[kythyria]

These features should be as obnoxious to use as possible, because over-use will be amazingly annoying and encourage the development of homeservers and clients that completely ignore them.

[ajvsol]

Annoying for who? I can't think of a possible reason to make the feature hard to use.

Some people want full conversation history, some want only the last X minutes/hours/days/weeks/months. Or they just want certain conversations (rooms) to have this option. Some do it for privacy, others to keep their homeserver tidy with no maintenance.

As for implementation, I'd follow Signal and have a configurable self-destruct timer in room settings with a timer icon under each message.

[kyrias]

Thing is that you cannot ever rely on a feature like that to do anything since it would be incredibly easy to change your server to not care about the setting, and the more they're used the more likely it's going to be for there to be a popular client/server fork that doesn't follow it, because most other people doesn't want random messages just disappearing out of the blue.

So if you rely on something like this for privacy, you're bound to get bitten in the ass from the false sense of security. If anything what would be more useful is to use encrypted rooms and for clients to have a button for destroying the keys it has for a room, and then both parties could destroy the keys to read old messages that way.

[ghost]

An idea: allow Synapse home servers to set an option whether to delete redacted/self-destructed messages or not and visibly show information about this in every user's info.

[MurzNN]

Implement self-destructing message at first we can via bot with admin rights, that will delete (redact) all messages older than specific time. And if this will be popular - implement in Matrix client interface.

And additional server option for homeserver owners in Synapse 'Remove deleted (redacted) message from homeserver database' with warning 'Acts only on current homeserver database, deleted messages may kept on other homeservers with disabled this option'.

[t3chguy]

It can't be done in a matrix client, because what if your client is offline then your messages wouldn't be removed. Bot would be fine as that'd be online all the time

[MurzNN]

Here is issue about Matrix room history purge bot turt2live/matrix-wishlist#81

[Nostradamos]

It can't be done in a matrix client, because what if your client is offline then your messages wouldn't be removed. Bot would be fine as that'd be online all the time

Depends on when you want to destroy the messages. For example telegram deletes them after a user had read the message. So this would be more of an "destroy x time after read". This behaviour could also not be implemented in a bot, because the bot would need to redact device/user specific messages.

[mtausig]

I'm afraid, disappearing messages in Matrix would be quite a bit more complicated or less user friendly then in Signal. Signal deletes messages only locally on the phones while Matrix redaction works on the server.

Thus the Signal behaviour of Delete message on A's phone x minutes after A has read it won't work. We could only do Delete message in the root x minutes after everyone has read it. And even that breaks completely, if there is an inactive user in the room or any user has disabled Read notifications.

So we would probably need not one, but two timers to be set. One for every user has read the message and one (longer) fallback, where the message gets deleted no matter who has read it.

[ara4n]

there's a proposal for this now at matrix-org/matrix-spec-proposals#1763

[aaronraimist]

New proposal is matrix-org/matrix-spec-proposals#2228

[Thatoo]

and an other one here, merged into develop : matrix-org/synapse#6409

[ara4n]

that's not a proposal, that's the implementation ;P

[Thatoo]

even better then 😃

[MurzNN]

So it released in Synapse 1.7.0rc1, now waiting implementation in Riot UI?

[Biep]

This is an (important) special case of #364.

[aldaw]

Please can not swap otherwise to matrix! But really want to! :(

[snicky-panda]

A lot of activists in Belarus protests started using Element for encrypted chat communication. We are using it both from mobile and desktop versions. Due to the high risk of detention and high interest of the police in communication channels (they are forcing people to unlock their phones up to torture cases) people ask for cleaning up the message archives to avoid any leak of sensitive data to the regime.

• Describe the solution you'd like

Self-destructing messages are highly important for automation of cleaning the history and making sure that no extra data left behind. As i understood this is already implemented in Synapse here and just needs implementation for the UI. By implementing this you are helping to fight the dictatorship :)

[mattcoxonline]

I would love to see this happen. The important use cases are as @snicky-panda described. A more trivial use-case is mine:

I run a server through Element Matrix Services for friends and friends-of-friends and everyone on that server is in agreement that nobody needs to keep copies of their messages older than a month or two. We definitely don't need anyone to see copies of our messages from a year ago.

It's one thing to allow the individual user to set a destruction time on individual messages or conversations, but it would be great if I could set a default destruction time for all messages on the server.

[t3chguy]

That is a thing synapse supports. Talk to your EMS support contact about setting up retention periods. @mattcoxonline

[MurzNN]

That is a thing synapse supports.

Synapse supports this well, and deletes well on server side. But Element on client side - do the local cache of messages, and show them long time, even after they deleted from server! And this is really confusing for users! Clearing caches manually every day is help, but too annoying.

Is it hard to implement, at least, matching ttl for locally cached messages on rooms, having message retention states, to auto-delete them from devices too?

[t3chguy]

That's because synapse does not whatsoever tell Element it has deleted anything.

[MurzNN]

As I understand from previous discuss, the position of Synapse side is that Element (and other Matrix clients) must follow the m.room.retention room state event, and make message deletion from cache by yourself, instead of waiting some signals from Synapse to delete concrete message from cache.

[t3chguy]

The issue is if you configure the setting in homeserver.yaml then the state event won't be set.

[trymeouteh]

matrix-org/synapse#6287

I created this issue in hopes that they will create a standard for self destructing messages within Matrix with many options.

I hope this can be developed and released for Matrix and then the clients such as Element can implement it.

[Mikaela]

Considering how this is partially implemented in a way that is invisible to most of users, I opened element-hq/element-web#18630 worrying about the abuse potential for e.g. gaslighting.

The solution I would like to see is something like in Telegram, where when a group has disappearing messages enabled, there is an indicator next to the text input bar:

• 
  • See the fourth icon on the right.
• 
  • which then brings up options for message automatic removal: disabled, 1 day, 1 week (selected) or 1 month.

[Biep]

That would go nicely with the broader proposal.

[xanoni]

These features should be as obnoxious to use as possible, because over-use will be amazingly annoying and encourage the development of homeservers and clients that completely ignore them.

Strongly disagree with this view. I use disappearing messages for 97% of all my IM conversations. Signal has it and Telegram E2E has it. Session has it. Molly has it. Heck, even WhatsApp and SnapChat have it !!! For Matrix I use this workaround: https://github.com/commonism/matrix-archive-sso/tree/redact

I very, very, very rarely need any messages that are older than a week or so. Keeping them is just not worth the risk. Let's help people with their data hygiene.

A few inputs, so we can skip one or two iterations:

1. Let's allow users to define their own intervals (X hours, X days, X weeks) instead of giving just 3-5 options. It doesn't cost much to allow this flexibility. People have different preferences and needs. (Signal has added this after people kept asking for it.)
2. Let's allow users to make this the default for all conversations. (Signal has added this after people kept asking for it.)
3. Let's explain to users in the settings what this is NOT (i.e., most home servers don't actually delete the messages, thus it is critical that E2E encryption is also used).

[Biep]

Yes indeed - the lifetimes proposal seems to give just what you ask, and more. Maybe close this issue and continue there?
I'll give my other comments there.

[Mikaela]

I hope Element and Matrix blogs/social media/marketing constantly discussing interoperability, WhatsApp and Telegram, means this feature is going to move forwards as from these three only Matrix/Element has no stable way of automatically removing messages.

Currently I can simply enable that in either Telegram or WhatsApp and I have no idea whether the current bridges support that and the only similar feature here is m.room.retention that I find actively discouraged.

[SethFalco]

I'd really like to see this, but on a per-message basis.

I'd really like if users could set a TTL on individual messages and/or media on a per-message basis. (Namely for attachments, though!)

The main reason is to reduce storage burden/cost on the homeserver. For example, 99% of files I've attached to messages are only needed for that short exchange. I'd love if I could indicate to the homeserver that there is no need to hold on to it once it's been downloaded or after x period of time.

On the side, I also do like the idea of deleting sensitive things from other servers, even if it's already encrypted. If it's not needed, it doesn't have to be there.

A use-case could be, I attach my CV to a friend. Instead of depending on the homeserver's configuration for media lifetime, I can just say "TTL 7 Days" and the attachment will no longer be accessible after 7 days of sending the message.
Another might be, I'm dumping all of my books (Creative Commons/Open Documentation License) to share with friends, but don't need to keep all of that on the homeserver once it's been downloaded, so it's wasting space.

One noteworthy concern was that users may send malicious messages or illegal attachments and get around moderation thanks to the TTL. In this case, metadata or the message itself could be retained if the message is reported before the TTL elapses.

---

A crappy UI mock up could look like this, in the attachment modal. (Note, I'm not a designer… clearly.)

Ideally, I'd like to see the options include:

• Delete on download.
• Delete after x period of days.

Mockup HTML

<div id="background">
  <div id="attachment">
    <div id="top">
      <h1>Upload files</h1>
      <span>x</span>
    </div>
    <span>FILE abstract-algebra-theory-and-applications.pdf (1.55 MB)</span>
    
    <hr>
    
    <div id="ttl">
      <div id="ttl-section">
      <div id="checkbox"></div>
      <span>Time-To-Live</span>
    </div>
    
      <div id="select">
         
        <input type="radio">1 Day</input>    
        <input type="radio">7 Days</input>    
        <input type="radio">31 Days</input>    
        <input type="radio">Other</input>    
      </div>
    </div>

  <div id="custom">
    <input type="number"/> <span id="label">Day(s)</span>
</div>
    
    <div id="buttons">
      <div id="upload-button">Upload</div>
    </div>
  </div>
</div>

body {
  background-color: black;
}

#attachment {
  background-color: #15191e;
  color: white;
  font-family: sans-serif;
  border-radius: .5em;
  padding: 1em;
  width: 512px;
}

#top {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

#buttons {
  margin-top: 1em;
  display: flex;
  justify-content: flex-end;
}

#upload-button {
  background-color: #0dbd8b;
  border-radius: .5em;
  padding: .5em;
}

#ttl-section {
  display: flex;
  align-items: center;
}

#checkbox {
  margin-right: .5em;
  height: 1em;
  width: 1em;
  border: solid #EEEEEE;
  border-radius: .2em;
}

hr {
  margin: 2em 1em;
}

#ttl {
  display: flex;
  justify-content: space-between;
}

#custom {
  display: flex;
  justify-content: flex-end;
  margin-top: .5em;
}

#label {
  padding-left: .5em;
}

[Biep]

@SethFalco

You might like the more comprehensive proposal #364 .

[roughnecks]

What's the current status of this?

[kittykat]

What's the current status of this?

Unfortunately it didn't make it onto the priority list for this year. I believe this issue needs product team's input before it can be addressed/

Moving to discussions as the topic will need a development issue when it is scheduled.