I think it might be best for you to take this to the official Signal forum if you want to see this changed.
There have however been quite many such posts and they’ve been discussed a lot of times so don’t expect too much traction or very nice answers.
Very well put! And politely…
The Signal forum, as ‘unofficial’ as it purports to be, is not the sort of place to discuss anything. Many years ago, it was “okay”. It is quite a hostile area with questionable moderation.
As much as this specific topic doesn’t affect me, I’m pleased to read about the discussion here in PG. It would highly likely be abruptly closed down over there quicker than you can say “supercalifragilisticnarcissisticpersonalitydisorderexpialidocious”
I think the problem here is that it is much easier for a non “real time messaging” service, otherwise known as email in this case, to implement a system in which the client is prevented from viewing the edit history.
I do suppose this differentiation is a little less clear given that IMAP is, more or less, constantly syncing with the email server, where as traditional POP email only synced with (and fetched from) the server at the active demand of the user.
With regard to assuming edit history is visible:
I do think Signal could potentially give a clearer warning (in app perhaps) that edit history is visible, but I do not see this reason alone as justification enough to remove the ability to see edit history from messages that have “yet to be read”.
I also think that, as others have said in this thread, defining when a message is actually unread vs just not viewed in app would add enough complexity that the simpler approach to removing edit history for these messages would be to do so universally, and personally I see to much value in edit history for that to be worth it.
I will say that I do not personally send particularly long/complex messages over signal, and many of my communications on there are with people who understand my writing style and process, so perhaps I just don’t fit the scenario of having to hide my edits on Signal.
When I do need to write to less personally acquainted individuals, or in a more formal setting I often draft my intended writing at least once before sending in the hopes of avoiding edits after the fact.
Side Notes:
Scheduled message sending feels like a separate issue, though I 100% rely on such features myself.
The edit history on this forum has been hidden for some time now because of this topic from 2024
Where exactly is the screenshot you provided from? As going to settings → chats in the official Signal Android app, does not show these settings. At least as far as I could tell anyway.
This is fascinating. I did not know about these settings. Thank you for informing me.
I am guessing they are disabled by default?
I don’t see them either. Would appreciate some clarification @uninvitedfriend.
I agree. Although Snapchat is not a messaging app anyone should trust for privacy, I remember hearing stories about women, sometimes even minors, having sent explicit disappearing pictures to a boyfriend and being shocked to find out that with a simple screenshot, those pictures were shared without their consent.
That may not be a bad idea.
I don’t know what you mean by “nice answers”. I don’t expect everyone to agree with me, and I welcome disagreements as long as they’re expressed politely. Also, this post was intentionally addressed to the forum, not Signal. My goal is to gauge the opinion of people here and have a discussion, which we are having.
I did not know that. Thanks for the heads-up.
That would be a step in the right direction. If people are made aware, then they have more control. If you had a pop-up warning every time you’re about to edit a message for the first time during any given day, it would be very effective without being too cumbersome. Either once a day for the first chat in which you wish to edit a message or once a day for every chat in which you wish to edit a message for the first time during that day.
I understand.
That’s fair.
I get that, but the people I use Signal with are mostly the people closest to me (emotionally). Some of them are friends and relatives I have not seen in years, even though we know each other very well. And from my experience, even with close people, tone can easily be misinterpreted via text. Even emojis can miscommunicate a tone.
If you had just lost a loved one and a friend just sent you this: 
, I know some people who would be upset, including myself. Even though the intent may not be bad, I would personally take it as a form of disrespect.
I try to do that too.
I really hope Signal implements scheduled messages in the desktop app and that they add silent messages to both desktop and mobile.
I did not know that. Thanks for letting me know.
I assume a user can still see their own edits?
As far as I know, users can still see their own edits, yes.
As I only use signal on Android I tend to forget that scheduled messages aren’t available across all clients, which does suck in my opinion.
Fair
Huh, I use an unofficial Signal-FOSS and these settings are in Settings→ Chats, right at the very bottom. (Edit: And yes, they are disabled by default.)
I believe Signal-FOSS utilizes the degoogling patches from Molly, maybe these are cherry-picks? Not sure… (Edit: Someone using Molly would have to look, I guess.)
Then again, if these are anywhere, one must assume the protocol/feature set supports this, even if it is simply ignoring the deletion request.
I haven’t actually tested this, because I’m the one in my circles who made them use Signal. If I’m to tell them I can bypass this, it would leave a bad taste for them and they might feel confirmed to stay with WhatsApp. (As paradoxical as this is to us folks.)
I presume this is what you mean: https://www.twinhelix.com/apps/signal-foss/
Also adds new preferences to keep view-once messages, disable remote deletion, control media deletion, and disable expiring messages.
I am curious why you chose to use this fork of Signal instead of something like Molly instead.
Never heard of it. What is a Signal-FOSS? Is it another fork of Signal?
I thought Molly was the only one. I also though Signal was already FOSS.
I see.
Yeah, I can definitely imagine such a scenario. You’re not using the official app, you’re using a different one which gives you more control than the average user. I wonder if Signal is aware of this feature in their forks.
If you don’t use these features at all, I can see why you would deem it unnecessary to alert your contacts, but the second you use it, even if it’s just with one person who happens to a colleague, it becomes incumbent upon yourself to tell all your contacts IMHO.
If I was in your circle and knew that you used this feature with someone else, it wouldn’t matter that you promised not to use it with me, even if that promise was sincere.
Why did you opt for Signal-FOSS instead of the original app?
Off-topic:
I used the official app at first, then found out about Signal-FOSS in my quest to avoid any proprietary software whereever I feasibly can. This was pretty early for me (so details might be fuzzy) and I assumed it was an official FOSS flavor. Then tried Molly and it had a severe battery drain on my device. I went back to Signal-FOSS and later found out about it being unofficial (when I knew what I was doing).
I just stuck with it then, since Molly is more than I need and I didn’t want to check for the battery drain again (as isolated as these reports for me and others are). And I have to trust another party for both, so there wasn’t any personal benefit to switch again. Maybe these features prompt me to take another look at which app to use.
Signal is not completely FOSS, because it uses Google’s FCM for push notifications for example. Molly and Signal-FOSS use WebSocket, I believe. There are other things as well, I think some binaries or artifacts are either proprietary or at least not entirely free software. These apps patch those dependencies out when possible.
Thankfully, I’m of an age where not many associates would be inclined to do this. Whilst I could, I won’t. As much as it is largely out of my control, if I found out someone was not using the official client, I’d not communicate with them.
On the other hand, given the basic features of the official client compared to other similar communicators, I do fully understand why some may choose to use a Signal fork. Evidenced within this very thread and the questions around edited messages which, when you think about it, is arguably moot all the while forks are being used that bypass many other areas of concern.
This is probably off topic at this point but I generally would recommend against 3rd-party/unofficial clients for something as sensitive as Signal.
TeleMessage may have been a special case, but I can’t imagine other forks out there have similar problems (intentional or not).
I get where you are coming from, but there always will be a way to bypass these restrictions. Even if screenshots would not be permitted in the app and everyone uses the official one, one could always take a photo with another device of media or messages before they time out.
All in all, it’s just a safe messaging channel, without means to prevent circumventions on-device or after-sent.
We’ll go with Off-Topic, although arguably circles back to the topic at hand given the handling of editing messages and subsequent speak about forks. But I will concede (although irritating as I can’t quote within hidden text.
“Always be a way to bypass…”
Indeed. This comes back to the ‘threat model’ question. This isn’t within my threat model. My associates (and myself) do not use forks. This is intentional for a few reasons which is immaterial here (some lack capability, but a few do not but have agreed not to use forks for the sake of the groups we are in and who we speak with).
A lot of the time it is said about “speaking to adversaries”, which I do not do. And that argument has its own flaws in any case.
The OP’s question fits in with this. I’d largely agree with what is suggested, particularly for my usage. Not so much for those using forked clients due to the bypassing in any case. But then I mitigate with what is suggested by the OP and delete the message and re-post. None of this will then be known to the recipient (other than it’s been deleted). Unless, of course, they bypass this. See: fork above.
I think this is an edge case and one could formulate a different case where its good that the honest version is preserved for the reciepent
This post has been stuck in my craw for a few days now. I’m not a journalist, but I imagine there are cases where seeing the history of edits they missed can be helpful to reveal if a source is being consistent, making slight corrections or sizable changes to message content. Similar situations likely occur with government officials who use Signal for secure communication, where information needs to be recorded and not so flippantly malleable. The OP’s almost solipsistic insistence that the technology is faulty because they can think of a scenario or two where it could slightly inconvenient and unwillingness to imagine its value is honestly exhausting and counterproductive to actual privacy discussion.
The bright side of this, I suppose, is that it has made clear to me that this is not a forum to engage in meaningful privacy discussion, and I should put me energy elsewhere. So that’s nice.
I can’t work out if this is humour or not.
It’s a discussion. This means you will hear from both sides or even many sides. Whether you agree or not is immaterial. This is, quite literally, discourse.
Really?!
Thanks for explaining.
I did not know that.
IMO, Signal has made a ton of progress in the last couple of years. It’s people like @maqp who made me understand why Signal was so slow to release new features compared to apps like Telegram. It’s because, unlike Telegram and WhatsApp, Signal’s priority is always privacy. E2EE is baked into every feature, and it is very hard to achieve, which is why it takes time.
With this insight, I gained a lot more respect for Signal, and I find myself to be more patient with their release of features. But I can appreciate that for some people, even in the privacy community, it is still lacking.
I never thought that a fork would make it easy to exploit vulnerabilities.
This is new knowledge for me.
This was just one example I gave among several. I reject the idea that the first draft or any draft that came before the final one is the “honest” version. It suggests that the final version of any text is inherently dishonest, which is preposterous.
There certainly are. I don’t deny that.
It depends. I imagine that there are protocols in place. Since the Signalgate scandal, it has been my understanding that only low-level and, at best, mid-level government employees are given the OK to use Signal in an official capacity. High-level government employees are not allowed.
You would be surprised how many times I hired or consulted an expert in a given field to give me an opinion on something, and they tell me things orally that they refuse to confirm in writing. Like they’ll tell me something was not built up to code but will not explicitly confirm it in writing, even though they believe it 100%. It’s happened enough times that it has made me consider recording conversations every time I hire an expert.
This is also why every time I contact a local business or organization I need a service from, I do it in writing first via email. If they don’t respond to my emails, I call them. And after they give me the information I need over the phone, I ask them to confirm it in writing. Multiple times, a company quoted me one price in person and a different one when I called them over the phone, which is why I always ask for confirmation in writing.
You’re putting words in my mouth. I never said or suggested that it was faulty.
There are various ways to implement edited messages, as not all apps do it the same way. I simply shared my critique of Signal’s implementation and asked the PG community what they thought about it.
Clearly, you have not been following the thread because I have conceded multiple points that others have made, which evidently indicate that I can appreciate the value that people see in it.
I am surprised too. I have found this discussion very engaging and have learned a lot from other people’s views. Just because I don’t agree with someone doesn’t mean their feedback is not valuable to me. The overwhelming majority of the time, hearing other people’s feedback sharpens my perspective. I enjoy the exchanges we have.
I would not call it vulnerabilities, maybe an exploit, but that’s also a bit much.
You always have to assume you cannot correct anything once you pressed the send button, no two ways about it. Reasons being:
The only (flawed and incomplete) way around some of this would be a private notification/message without sender and content (handshake “message”), enforcing a reception response as soon as the app is open and only then let the server send the actual message, making any remote function for the sender obsolete again.
(Something like this, where -/> indicates end of influence of sender:
Sender sends message to server -> server sends notification for undisclosed message to recipient -> recipient sends acknowledgment to server or sender, if disclosed -/> sender auto-authorizes server if not stopped before -> server sends message to recipient)
(Also, given the arguments above, reports for sent/received / check marks in general are a mere convenience as of now and don’t serve a verifiable purpose at all.)
What you send is out of your hands by the time the recipient receives it. There’s no guarantee that the recipient’s device will abide by any request to delete or edit the message. Giving the sender vague promises about what you can achieve is poor design. The only place I see for it is collective agreement against third parties, basically, disappearing messages.
The weird part is the edit feature retains the original message, but you can destroy remotely the sent message. The disparity between should be either explained, or resolved to either direction. Deleting the messages is useful if you want to take back what you said, but the “this message was deleted” messages can be even more eyebrow raising in some cases.
Remote message deletion does answer a “I need to get rid of this message but I can’t reach them and we don’t have disappearing messages enabled now” threat model so I kind of get it.
The trade of is cyber bullying etc where you don’t want the other person to walk over your right to retain evidence on your device.
It would be interesting to know how Signal behaves if you block someone, can they still issue message deletion requests.