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]

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.

[rriemann]

This is an important feature for companies to improve their GDPR compliance. In GDPR, storing personal data without time limit is against the data minimisation and storage limitation principle.

https://gdpr.algolia.com/gdpr-article-5

When companies offer chat via matrix amongst employees – possibly on company-provided managed phones –, the problem of non-trusted servers does not apply. It is a closed environment. Imagine:

1. a video call with job applicants. For ease of use, you may want to reuse a room with a fixed address without keeping applicant data forever.
2. a room to decide on the next common coffee break. I do not want that people can scroll back months to study my coffee breaks.
3. a room to send holiday greetings. I do not want those greetings (possibly with picture) retained forever. 1 week would be good.

[Biep]

For several of those things you'd rather want message lifetimes, so that you can also do things such as only showing the invitation to the common break shortly before it begins (even though you are not on Matrix then), and not show it after it has started to those who didn't read it before.

[toger5]

There is also the futures msc that superseeds lifetimes in a more generic way: matrix-org/matrix-spec-proposals#4140

It allows sending scheduled messages so you can schdule a redact and get the disappearing message with the current matrix redaction semantics.

[Biep]

Does that allow setting a starting point? I haven't read all, but could only see stuff concerning an end point in time for the messages. Or is that what the reference to Futures is about?
If so, it seems indeed to implement lifetimes to a large degree.

[toger5]

It basically only allows setting a starting point. But the start of the redact is equivalent to the end of a normal room message.

if you want to make it complicated you could also send a future for sending a message in 1h and another future to send a redact in 2h. It provides that flexibility. So its scheduled and disappearing messages in one.

[Biep]

Good! That sounds like an implementation for much of #712.
What about dropping the message if it has not been delivered before a certain time (instead of sending and redacting it)? The moment T in #712?

[Biep]

And of course it does not address the (purely client) "keep trying" part, which is so important in rural West-Africa, where Internet access is sporadic. (Many of my contacts there tend to walk around searching for connection, and then have to go to all their rooms to trigger the sending of the pre-written messages, which is a bother.)

[Mikaela]

Yet another reason why there should be possibility for self-destructing messages is combating climate change as many of us have old messages that we won't miss and that are using up storage somewhere as they keep cumulating and that storage uses electricity which may be unclean or taking electricity that could be used by something else.

• https://www.theguardian.com/media/article/2024/aug/09/excess-memes-photos-and-reply-all-emails-are-bad-for-climate-finds-study

[toger5]

This is an interesting thesis.
I would like to comment on this since there clearly is a misunderstanding in how matrix works.
Matrix stores messages in a Direction acyclic graph (DAG) to synchronize data in a distributed system. A DAG (as the name implies) is a Directional data structure where you cannot "go backwards". So also a delete and a edit does not alter the historic data/events. Instead each redact/deletion is a new event that gets appended to the graph.
The home servers can remove the content of the messages. In most cases they are less data however than the new redaction event.
But it would be an interesting experiment so see if one can find other areas that make sense to optimize.
The matrix rust SDK already has a lot of optimizations (hence saves electricity) compared to the legacy apps kotlin/java and swift/obj-c SDK.
In general matrix messaging apps have a small leverage in a climate impacting energy consumption compared to other industries/projects. I think there are much better fields where the return of investment and hence the impact of resources have a much much larger outcome and positive impact on making the best out of the situation of the global climate.

[throwException]

I also think this is a really important feature.

Even if there are some clients and servers who don't follow these rules, in activist/political organizations it's common that everyone uses Element, the server is hosted by the organization and everyone is well-behaved until the day of a police raid where they confiscate devices. At that point, it's great if most old messages are deleted from devices and servers.