Signal-desktop: Stop storing more than 100 messages on your server without our consent

[patlecat]

I reported this before but it was sadly not taken seriously. But on the desktop version Signal sometimes downloads more than 1'000 messages from the server! And it may do the same on the mobile apps.
All Signal programs have to offer an option to limit the number of messages stored on your servers. Anything beyond a 100 msg is suspicious and risky, but at least have the decency to get an explicit consent from the user! In every chat, the lower number is to be taken!

[Trolldemorted]

Why is anything beyond 100 messages suspicious? I sometimes receive several hundeds of messages per day.

[grovesp]

Is this the normal behavior? That's not only a lot of additional storage for Signal, it's a potential risk if there's a successful MITM attack or there's a compromise which would render those messages readable.

Ideally, NO messages would be available/archived unless the user took steps to do that. Can we confirm how many actual messages are stored? What's the data retention process for these?

[gasi-signal]

To clarify, messages are only stored on the server until a client connects and downloads them. The queue for each device (Signal Desktop, Signal Android, Signal iOS) is 1000 messages (all types, see below) and they are stored encrypted. Once you download them, they are gone from the server.

The download counter during startup of Signal Desktop counts all messages types, not just user visible messages from other people, e.g. contact sync, verified change, read receipts, etc.

If you’d prefer a lower number of messages stored, what do you propose should happen for incoming messages after your queue is full? Should we drop the newest ones? The oldest ones?

[Trolldemorted]

Could we get bigger queues? The queues of my desktops are overrun everytime I go on a vacation.

[grovesp]

Thanks for the concise explanation, @gasi-signal -- makes a lot of sense. How does this work with multiple authorized devices? Is it multiple queues on the server?

And, I agree that if the functionality is based on ensuring messages are delivered, it doesn't make sense to truncate any of them. What occurs when an event like @Trolldemorted is describing occurs - is there an error message relayed to the sender? Do things just stop?

[Trolldemorted]

Each device has its own queue.

If a device stays offline for too many messages the session silently breaks. Happens everytime a signal-desktop device in our group stays off for a week.

[patlecat]

@gasi-signal "To clarify, messages are only stored on the server until a client connects and downloads them." Unfortunately that is not true. Because as you say you store over 1000 message for every device, so if I use 2 phones and 2 PCs then you will actually store over 4000 msg in the servers. And that is ludicrous and only okay if I have schizophrenia with 4 personalities for each device!
Give us users the right to choose, we know better what we want. For those that love to have tens of thousands of messages stored on your server that is fine. For people who's life depends on your service keeping them safe that is not good enough.

[Trolldemorted]

No, users do not know better what they want. Why should the size of the queue have an impact on security?

[Dyras]

Can someone please explain to me what difference it makes? They are encrypted, they could store a million messages and they still won't be able to open them without my private encryption key.

[grovesp]

@Trolldemorted -- simple risk equation -- more stored messages means more risk if keys are exposed. One message in some cases could be considered fatal. Just depends on who's using Signal.

@Dyras -- the problem is not the vulnerabilities we know about, it's the ones we don't. A failed key exchange or local exposure that exposes the "hash ratchet," and every stored message could be at risk.

Perhaps an option not to set the volume of messages stored; rather, the ability to NOT store at all from the either the sender or recipient? Taking failed sends into account, the server could cache a limited number for a short time, then provide a reject message based on the inability to deliver. Sender turns it off, then they get a notice the msg could not be delivered. If the sender has it off, then they only get a notice they missed a message and the sender gets the msg could not be delivered.

Just thinking out loud, of course.

_Edit:_ This sounds like something similar to what @Trolldemorted mentioned earlier when enough time lapses and the session silently breaks. Just with a notification.

[Trolldemorted]

@grovesp That risk equation is a bit naive.

If an adversary wants to decrypt messages, he or she has to

• break the encryption between the signal devices and the signal server (that means compromise the signal server or guess their TLS private key and conduct a MITM attack) and
• attain the corresponding message key (that means compromise one device or guess the key)

If the adversary can guess the keys, you are screwed. Luckily this is sufficiently unlikely.
If the adversary can compromise your devices, you are screwed. The keys are irrelevant though, because the messages will be on the compromised device itself.

[gasi-signal]

@Trolldemorted: Could we get bigger queues? The queues of my desktops are overrun everytime I go on a vacation.

That is something we might consider if we can ensure the stability of our server and databases.

@grovesp Perhaps an option not to set the volume of messages stored; rather, the ability to NOT store at all from the either the sender or recipient?

Yes, this is a hypothetical option but it would make Signal an online-only protocol / service. We are an online + offline messaging service, meaning you can write people regardless of whether they are online or not. This is a big value proposition for our customers and I don’t think it will change.

We have queues on the server ‘by design’ to provide the best possible user experience so I will lock this conversation for further discussion.