Let's enumerate the purported problems:
- "Elon Musk said so", which does not matter. - Signal attachments can be viewed by an attacker with local access to the client. This is not Signal's job to protect against. - Signal offers an optional `--no-sandbox` flag which only has security options if enabled on Linux. - Weaknesses in sealed sender. This is the only one that might be an actual problem (two theoretical and one empirical attack, but the latter comes from an 18 page paper that I have not read). But this does not compromise the integrity of the chats, and is not something Telegram improves on.
Given how the posted described the optional `--no-sandbox` flag as "no sandbox on Linux", it's clear that they don't understand anything they're sharing, and they just want to spread FUD.
---
edit: Per discussion below, I was wrong about the `--no-sandbox` flag. It's enabled by default. The risk is that an attacker could figure out how to use Signal to run arbitrary JavaScript. I take back my insult- it was I who did not understand the linked issue.
I still stand by Signal > Telegram. The risk here is that an attacker could figure out how to abuse Signal to run arbitrary Javascript, e.g. through a specially crafted message.
Could you elaborate as you seem to be more "knowledgeable". This flag is clear at what it does and shouldn't be shipped into production. https://no-sandbox.io/
You can have a look where they specifically chose to force it https://github.com/signalapp/Signal-Desktop/commit/1ca0d8210...
Can confirm with `cat /usr/share/applications/signal-desktop.desktop`.
This still would require a pretty sophisticated attack to take advantage of, but I wouldn't rule it out as an attack surface. (We regularly see iPhone exploits that attack font and image rendering, after all.)
I'll amend my post given this.
There's an issue open to provide a flatpak for the app.