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?

[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;
}

[hoka99]

This seems like unnecessary work to build in a use case for single messages when you can just turn on disappearing messages and turn it off again when you send your message (ex. Signal). This type of feature is already implemented in every chat app with a consistent behavior and matrix should follow that lead, I don't believe matrix should be try to build some one off feature no other app supports.

[SethFalco]

The important thing to me is that it can be done per-user, rather than depending on the space, chat room, or homeserver configuration. So long as we have that, then I could get behind anything tbh. 👍🏾

The reason I favored a UI where it was per message is because I'm more inclined to leave text messages up, but automatically remove my attachments.

If we rely on the TTL being a setting on the account only, I'd at least like to have the means to change the TTL through a command, shortcut, or a little drop-down next to the send button. (Not sure about the command part, but a shortcut or drop-down would be Element specific ofc.)

[Biep]

Having an easy to set default is always good. Two defaults would be better: one for messages, and one for (large) files.
But having the option to decide on a case-by-case basis is good too. Pinned messages typically should not be destroyed. And sometimes I send a password, and want that to go away after a few minutes, for in case the receiver lets her device around on a non-safe location.

In the more comprehensive Message lifetimes proposal, making choices depending on the nature of the message would of course be paramount - a birthday greeting should be delivered later, but other messages not, for instance. And that means that even if that proposal is not implemented fully the first time, the restricted version that is should be extensible to the full version.

[Biep]

@SethFalco

You might like the more comprehensive proposal #712 .

[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.

[vasyugan]

Are there any objections against adding such a feature or is this due to lack of manpower? If the latter, it would make sense to look into external funding options ad donors who provide grants for IT security for civic activism. This seems like the number one showstopper for endangered activists and human rights defenders to start adopting it.

[Biep]

Please make sure it is not "solved" in a way that precludes extending it, as described in #712.

[MagicRB]

I'm not familiar with how matrix works internally, but as a stop-gap solution how effective would a bot be? I just need it to delete all messages which are 7 days or older from a list of rooms. Nothings fancy or per message, just a hard purge. I'm wondering how the clients handle this.

[wokawoka]

very much needed

[vasyugan]

For my peers, who are vulnerable human rights defenders, the lack of self-destructing messages is the number one showstopper and the reason why they all stick with signal, even though it requires a phone number.

[sc0w]

Same here. Self-destructing messages are the main feature missing before Matrix can replace XMPP or Signal for some activist groups we support.

If the reason why this much needed feature hasn't been implemented yet is just lack of manpower and if there are no principal objections, we might look into external funding options.

maybe https://bountysource.com ?

[vasyugan]

maybe https://bountysource.com ?

As far as I know, bountysource has changed their terms of use in such a way that they just keep unused funds for themselves after a while. What I am thinking of is whether obtaining a digital security grant from a donor such as this one is possible and sensible. If this is possible, an actual project would have to be drafted, terms of reference drawn up and a programmer hired to do the job in a timely fashion. At bountysource, requests can just linger there forever (and the money, AFAIK, can ultimately be kept by the company behind bountysource, and you will get NOTHING in return).

[SethFalco]

Another viable option for such a grant could be FUTO. In fact, they've already given a grant to Signal. They seek open-source projects that are giving individuals back control, so Matrix/Element and the very use-case described here are both very fitting.

https://futo.org/grants/

[vasyugan]

Another viable option for such a grant could be FUTO. In fact, they've already given a grant to Signal. They seek open-source projects that are giving individuals back control, so Matrix/Element and the very use-case described here are both very fitting.

https://futo.org/grants/

Thanks! Will have a look! Access Now unfortunately does not accept unsolicited applications, you have to be referred to them by "our global network of partners", whoever that may be.

[Cartasiane]

I'll would be happy to help organizing a fundraising

[Biep]

Self-destruction is likely to create a false sense of security: as Matrix is federated, no-one has control over what happens elsewhere. Servers may decline actually to remove "destroyed" messages. The best that can be done is have clients refuse to call the message from the server, or have (rightly) trusted servers, and no room members on any other server.

On another line, proposal #712 may provide some extra goodies, such as messages not showing up before a given time. That too can be critical in dangerous situations.

[vasyugan]

Self-destruction is likely to create a false sense of security: as Matrix is federated, no-one has control over what happens elsewhere.

What matters to me is what happens on my device. Our partners need such a feature primarily because undeleted messages might compromise them during searches. But I freely admit, I don't understand the complexities. Maybe this could be implemented fully on the client side. I for my part wouldn't need it, because I don't live in an authoritarian mafia state, but some of my partners do, they would have to have the ability to turn it on, and maybe have a one-click solution for wiping all chats, or maybe to hide the application or something else that protects them from being compromised.

[SethFalco]

Self-destruction is likely to create a false sense of security

I entirely agree that nothing can be done to guarantee that a homeserver or client actually destroys the message. However, I still think this is a worthwhile discussion/feature.

I'd like to note explicitly, I do think your proposal/write up is far better than exclusively looking at self-destructing messages.

However, the goal isn't to provide a guarantee, malicious actors will easily be able to remove the logic that destroys content and move on. The motivation is the case of innocent individuals with stolen/confiscated devices, or concerns that the person on the other end may be negligent and not do enough to ensure the conversation is secure and confidential.

Possible examples:

• passwordless device
• confiscated device where the password is handed over (i.e. police)
• lack of full-disk encryption where, the drive can be connected elsewhere, browser cookies, etc extracted, potentially preserving authorization

[mejo-]

I see your theoretical point, but please don't neglect the situation where all members of a conversation trust each other and merely want to make sure that their messages get automatically deleted after some time, without the need to come back to the conversation and remove them manually.

[tuxayo]

@ vasyugan:
«need such a feature primarily because undeleted messages might compromise them during searches»

THIS, that's a non negligible risks mitigation.

[eNkKVS4HxHc9jaq]

There is no such thing as a false sense of security in regards to DELETED messages. It is the other way around. This does provide in terms of security.

[Cartasiane]

Hey, I as a journalist really need this features to start using Element.

As you may now in some country we and our sources face heavy risks (sometime deaths) if some repressive state caught us with message history.

I understand that this features is hard to implement and that we cannot guaranteed that every messages will be deleted on every server / client etc. But what matter the most for my security is that the message is delete on my device that I trust.

In the meantime, would a bot be a solution? Would it be possible to pay someone to implement this? We really need this.

[vasyugan]

Well, how do you want to configure a room to have disappearing messages if not via a protocol extension?

I have no idea. You said I should check out "a few RFC attempts at this in the past". Where can I find them?

[aaronraimist]

@vasyugan matrix-org/matrix-spec-proposals#2228
matrix-org/matrix-spec-proposals#1763

[SamiLehtinen]

Personal opinion and pro-tip - First of all, I don't think that all platforms are suitable for all use cases. - SimpleX is excellent for privacy (afaik, imho) - Yet users whine that it doesn't support huge public rooms. - I also wrote Matrix-TTL script, which deletes messages based on age. It can be used to redact aka delete room history as necessary. But Matrix performs really badly with deletes and it might seriously upset users. (I've been there and done that).

[Cartasiane]

Woow, I contacted Travis R from T2Bot and got some good news!

The [Element] team is looking at two implementations for expiring messages: time-limited and burn-after-reading. Both are expected to be configured by room admins and can optionally be used on a per-message basis as well. This gives 4 total ways the feature can be used, which might be implemented at different times as the team works through it all.

It looks like all 4 ways to send such messages is on track to be completed by the end of 2023, and one of the four ways available in Q3. Which of those 4 ways is still to be determined, but the thread you've found should have more information as the team gets closer to release.

[Biep]

Woow, I contacted Travis R from T2Bot and got some good news!

The [Element] team is looking at two implementations for expiring messages: time-limited and burn-after-reading. Both are expected to be configured by room admins and can optionally be used on a per-message basis as well. This gives 4 total ways the feature can be used, which might be implemented at different times as the team works through it all.
It looks like all 4 ways to send such messages is on track to be completed by the end of 2023, and one of the four ways available in Q3. Which of those 4 ways is still to be determined, but the thread you've found should have more information as the team gets closer to release.

Now let's hope they'll implement the full #712, and not make a design choice precluding that.

[flatsponge]

Elements should support self-destructing messages as a feature. This is a common and essential functionality in many other messaging apps like signal and telegram. Self-destructing messages can enhance privacy and security by automatically deleting messages after a predefined duration or trigger. This can reduce the risk of data breaches, unauthorized access, or forensic recovery of sensitive or personal information. While this feature may not guarantee complete protection in every situation, it can mitigate more than 99% of potential threats. This feature is urgently needed for matrix users. Please prioritize adding this feature as soon as possible.

[eNkKVS4HxHc9jaq]

Yeah man I'd appreciate this too...

[Logicwax]

How about, for direct messaging between two people where Olm is used (and where forward secrecy is used), why can't we just instruct clients to simply throw out the ephemeral session keys for those specific messages that are marked for TTL/self-destruction?. That way we don't have to obsess over whether servers delete messages or not (the information, client-side private keys, will just be removed forever, rendering those messages never to be decrypted ever again).

[piegamesde]

@eNkKVS4HxHc9jaq if that is what you worry about, then remember than an attacker (e.g. malicious/compromised home server) could always sniff the encrypted transport messages and decrypt then later on in your scenario. So it makes no difference, and for all intents and purposes we can treat encrypted messages without keys as non-existent.

[eNkKVS4HxHc9jaq]

@eNkKVS4HxHc9jaq if that is what you worry about, then remember than an attacker (e.g. malicious/compromised home server) could always sniff the encrypted transport messages and decrypt then later on in your scenario. So it makes no difference, and for all intents and purposes we can treat encrypted messages without keys as non-existent.

I like how you just entirely skipped over the hypothetical scenario which I've nentioned and just said the messages could be ”intercepted“.

No. They in-fact couldn't if they no longer exist. New messages? Sure. But that is not what I was talking about in the first place. I was specifically refering to old messages that were already sent in the past.

[Logicwax]

all fair points, but I consider all encrypted messages I send to be archived anyway by intelligence agencies. Obviously the best approach would be both (deleted the messages AND the keys on the client). Considering that federation brings lots of complexities into deleting messages, I'd rather we at least start somewhere. I'd rather clients throw away keys for starters. No sense in arguing about this when it's at least a win the direction we all want.

As for future quantum cracking, Signal has already implemented post-quantum encryption. Hopefully matrix will get to that soon as well.

[droptile]

Self destructing messages is fundamentally a simple feature: there is a standard metadata tag that messages have which tells clients and servers that comply with the Matrix protocol when to delete messages automatically. How exactly this is implemented is almost arbitrary, so long as it works as expected with software that complies with the Matrix protocol.

It has been stated before that ultimately someone can just use a camera to record the device to store the messages permanently, circumventing the self-destruction feature. Or a malicious client may ignore the self-destruct tag and keep messages forever. But unless you can beam messages into users heads without them ever being displayed on a screen, thats life. No privacy feature can defeat shoulder surfing in all its forms. Nevertheless, self-destructing messages is a feature that is useful, valuable, and in some cases mentioned previously in this discussion like journalists in certain non-permissive areas, it is a required feature for Matrix to be considered as a solution.

This feature has been requested for at least 7 years, and on a quick look through this discussion there have been multiple attempts to implement it, but none have succeeded. The lack of self-destructing messages sticks out like a sore thumb when Matrix is compared to nearly every other popular messenger like Signal, Telegram, and even Snapchat. It would be great news if self-destructing messages could make it into Matrix 2.0.

[Biep]

But there is much beyond the safety aspect - though that is an important part. That is why I much prefer proposal #712, because the fact that perfect security cannot be reached is no reason not to implement that. And of course it gives much more control over our messages than this one does.

[Mikaela]

matrix-org/matrix-viewer#47 brings this issue up to me again as Matrix is making it too easy to access past history of rooms going as far as to publishing members-only readable histories on a webpage (granted not indexed by search engines) for anyone who knows the link and thus potentially contributing towards social cooling and fighting against the right to make the mistakes.

• https://www.socialcooling.com/

[Cartasiane]

Any news / Things that can be done to push the making of this feature???

[droptile]

I fully understand that self destructing messages are not a silver bullet, but I am totally in support of their addition. There are many cases where the attacker isn't a l33t hacker but just someone who picks up your phone that was left unlocked playing a youtube video and scrolls through your messages. Being able to ensure that only 1 week, or 1 day, or 1 hour of recent messages exist on the participants devices (or at least on your own device) is a valuable privacy feature.