Signal-desktop: Destroyed messages - not that destroyed...

[TCB13]

Hello, first of all, many thanks for the great software that Signal is.

Now, I have a privacy-related concern about Signal. In some conversations, I have set Signal iOS to destroy messages after 30 minutes, and it appears to actually to destroy the messages, however whenever I launch the desktop App, I see the messages appearing - seems like the desktop client actually syncs everything from somewhere and them locally destroys the messages that have more than 30 minutes.

My questions:

1. Why is the desktop version showing stuff that is already destroyed?
2. Where are these messages stored? They don't appear on the iOS app because they have more than 30 minutes;
3. Do you store old messages on the Signal servers?
4. Do you store old content on my iOS device, even if it is automatically destroyed? If yes, how can I delete it?

I don't get why Signal works this way, from a privacy and protection perspective if one wants messages gone after 30 minutes they should really be gone - no backup on any device or server.

It looks like Signal does a lot of crap in the background that people are unaware of and that can be a security risk. If the messages are still stored on my phone after they are destroyed then, anyone, with some forensics software, can recover them; If they are stored on Signal's server... well... they are subject to law enforcement requests and it is just bad faith, sorry.

I think it is time for this issue to get fixed, more importantly for some transparency regarding how, when, where and why messages are stored.

[chiraag-nataraj]

I _think_ the way it works is that the messages are stored on the Signal servers until they have been delivered to all devices which are supposed to get them, at which point they are deleted from the server. The reason you are seeing this behavior is most likely because the desktop client is playing "catch-up" and the messages weren't deleted from the server because they hadn't been delivered yet.

One possible way to solve this is for the server to delete the mesage if it hasn't been delivered yet but has expired. I don't know how feasible it is though.

[minnmann]

Basically, @chiraag-nataraj is right.

I understand it that way:
Every device that you use has its own message queue. When your contact sends you a message, it is end-to-end encrypted for each device (yours and also his own) independently (such that only that specific device can decrypt the message) and stored on the server.
No received message gets synced from your phone to the linked devices (you can try that out by switching off your phone or putting it into airplane mode and still being able to chat via the Desktop client).

One important fact in this regard is that all the metadata - besides sender and recipient - is end-to-end encrypted as well (timestamp, quotes and for this issue most importantly also _the self-destruction timer_).
That means that the server does not have any knowledge about the properties of the message other than the sender and the recipient (and probably how many devices each have).

So if the server should be able to delete the message that has been expired, you would have to expose more metadata to the server, which I assume that Signal always tries to avoid and rather work towards zero knowledge from a server perspective as much as possible.

This results in the behavior that your Desktop client has to pull the messages first and then destroy them, if they have been expired (AFAIK, every device sends a message to other devices the moment the countdown begins).

If you feel like your messages do not get destroyed on you Desktop client at the correct moment, you could post a debug log such that the developers can investigate the issue.

In general, however, I assume that such discussions should take place at the community forum.

[TCB13]

@chiraag-nataraj and @minnmann many thanks for your input about this.

---

tl:dr; delete <message-id> request that would tell the server to delete a message - no metadata is leaked, unencrypted or somehow vulnerable. Could already be implemented, whenever someone deleted a device from their account all the messages pending delivery to that device are probably also deleted.

---

As you pointed everything is encrypted so, the server can't delete the messages on its own - nor should. Every device has its message queue and downloads everything from the servers and them destroys what is already expired.

The messages only get destroyed if some device has shown it to the user (and the counter has expired). What I noticed is that if device A marks the message as read and the counter has expired, device B will pull the message and delete it right away - meaning that there is a signaling mechanism that allows my phone to the tell the computer that I already viewed message X and thus it can be destroyed.

Why isn't there a similar mechanism so my phone can tell the server that it already destroyed some message and then the server would delete all copies pending delivery to other devices?

Following your logic, I believe the signaling mechanism is just the encrypted metadata o the message that has a "viewed date" property that my phone populates with the date whenever I see the message. Maybe the server could implement some command that Signal clients can use to delete all references of a message, this wouldn't necessarily require changes to the message data, metadata or anything unencrypted, just a simple delete <message-id> request that would tell the server to delete a message - no metadata is leaked, unencrypted or somehow vulnerable.

For instance, I've two computers and a phone connected to my Signal account. Sometimes I only go to one of those computers once a week - by your logic Signal is retaining on their servers a copy of every message encrypted for that device until it is turned on and the messages are delivered (and then destroyed because they have already expired). The signaling mechanism I suggested would a) protect everyone's privacy by actually removing all copies of a destroyed message on the server, b) reduce the number of useless messages Signal's servers store and c) improve syncing because clients wouldn't need to download an entire week of conversations before deleting them.

Additionally, this signaling mechanism could already be implemented. Whenever I go into settings > devices and delete a device what happens? Does Signal servers keep a copy of the messages waiting to be delivered to those devices or just delete them all right away? Probably the later. Why not do the same thing with messages already destroyed by some device?

[scottnonnenberg-signal]

@minnmann Was correct in his description of the per-device queue and the fact that the server doesn't know much at all about the messages being passed through it.

@TCB13 The right place for the hypotheticals you've provided is the forum: https://community.signalusers.org/

I will note that it sounds like you are seeing messages which you shouldn't, and you should create a separate bug with a full log and detailed description of the behavior you're seeing. Say for example you have a 10 minute timer, you receive messages on your Android device while your Desktop is not running, and then read those messages and they disappear on Android. What should happen when you start Desktop is: it receives the original expired messages, then it receives messages from your Android device saying that it has read those messages, and only then then does it consider those messages expired because you read them a while ago, so you never see them in Desktop.

You can run into problems if you read disappearing messages on a phone with spotty connections, or while in airplane mode. Desktop will never know that you've read those messages on another device.