> Doesn't that break Signal's security guarantees? For example, what if I set my message to delete in 1 hour but TM Sgnl archives it, or some other app simply ignores the retention setting?

Disappearing messages has never been a security guarantee of Signal. People can always archive things their own way (screenshots in the worst case). It's just a convenience feature, not a security thing.

> Disappearing messages has never been a security guarantee of Signal.

What makes you say that? Has Signal posted something about it?

Retention settings are widely used for messaging security.

Also, I just used retention as an example. There could be many other holes in the unofficial client, including how it communicates with the Signal network. Maybe my messages aren't E2EE when communicating with that client. Maybe the mess up the encrytion implementation.

> What makes you say that? Has Signal posted something about it?

I mean, if you want Signal's blog post where they introduced it, it's here: https://signal.org/blog/disappearing-messages/

But also, of course Signal hasn't promised that if they're remotely competent, because that's impossible. You can't stop people from retaining messages if they want to. Now perhaps they're not remotely competent, but in reality they do know better.

> Retention settings are widely used for messaging security.

I mean, maybe people think they're using it for that, but regardless of the context, it will not provide any actual security, because that's impossible! Your recipient could get out a camera and take a photograph if that's what it comes to.

> Your recipient could get out a camera and take a photograph if that's what it comes to.

You are making the perfect the enemy of the good. As I said, two comments up: "I suppose I must trust other users - they could always screenshot a conversation. But while I trust them not to intentionally cheat me, I shouldn't have to trust them to accurately evaluate the security implementation of a software application - something most people can't do, Mike Waltz being the most famous example."

IT security professionals do use retention settings for security; it's not perfect, as you say, but it's very helpful. For example, many businesses auto-delete messages after a certain period except messages that the user intentionally preserves.

And as I said, there are other security functions in Signal that users must trust their apps to handle correctly.

> You are making the perfect the enemy of the good.

They merely said: "Disappearing messages has never been a security guarantee of Signal".

Signal guarantees end-to-end encryption in transit. They don't guarantee anything that happens on the phones, because they can't. They try to help where they can, e.g. with disappearing messages. But that is a convenience tool, not a security guarantee by Signal.

We agree; you just seem to want to argue with a strawperson.

My point is that they could help a lot more by verifying the clients.

> Signal guarantees end-to-end encryption in transit.

They can't guarantee that unofficial clients do E2EE. For example, what if the client sent messages in a way that leaked information, including contact information of the users?

> But that is a convenience tool

It's a security tool, it's just not guaranteed.

I see responses like yours quite often. They are correct, of course, but if users keep getting confused about it, may be the UX is bad.

People have been requesting various changes to this feature for years, but hear crickets from Signal.

There's no way for Signal to prevent any piece of code that can make a TCP connection and speak its protocol from using the service.

While that's true even in the general case (through reverse engineering), it's especially true in the case of Signal because it's open source.

There are libraries for interacting with Signal services (one from Signal themselves), here is a CLI tool that uses a patched official library: <https://github.com/AsamK/signal-cli>

You'd need hardware attestation, but you can essentially implement DRM like schemes that prevent any unofficial client from working.

Why not require keys signed with Signal's private key?

If the keys are generated on the device, they can't be trusted by Signal since any clone could generate them too. If the keys are generated by Signal and sent to the device, they can be intercepted and used in any clone

Thanks. Signal could use unique public keys for each valid client. It could be intercepted and used for DoS against the valid client's Signal service, but that's not a confidentiality risk. It could serve as a UID, but maybe there are workarounds to that.

If it quacks like the official Signal client, there's no way for the Signal network to know that it's otherwise.

There are many solutions to this problem, such as cryptographic signatures.

The only solution to this problem is for your device to be tightly sealed so you can't modify the operating system nor access the CPU's private key.

The question is - how do you intend to verify whether an application is official or unofficial? What's stopping the official application to be 'patched' with a fake signature feigning validity?

How? If you're validating a server, sure. But a server validating a client?

Anything you ship with the app can be extracted.