3 ms·

Well... if you scrolled up a bit you would have found https://discuss.privacyguides.net/t/according-to-elon-musk-signal-has-known-vulnerabilities-that-are-not-b

Well... if you scrolled up a bit you would have found https://discuss.privacyguides.net/t/according-to-elon-musk-signal-has-known-vulnerabilities-that-are-not-being-addressed/18206/14 https://discuss.privacyguides.net/t/according-to-elon-musk-s... which says Signal isn't great either.

lynndotpy 2y ago
No, it does not. 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.
- ementally 2y ago
  >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. 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/ https://no-sandbox.io/ You can have a look where they specifically chose to force it https://github.com/signalapp/Signal-Desktop/commit/1ca0d821078286d5953cf0d598e6b97710f816ef https://github.com/signalapp/Signal-Desktop/commit/1ca0d8210...
  - lynndotpy 2y ago
    You're right. It seems I am eating my words on that item, the `--no-sandbox` flag does seem to be on in most Linux installs. From context and search, it looks necessary for it to work on Debian. 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.
    - ementally 2y ago
      No worries, but it is a legitimate attack vector given that sandboxing on Linux sucks unlike Windows and macOS, so it is much needed. There's an issue open to provide a flatpak for the app. https://github.com/signalapp/Signal-Desktop/issues/1639 https://github.com/signalapp/Signal-Desktop/issues/1639

lynndotpy 2y ago

No, it does not. 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.

ementally 2y ago
>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. 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/ https://no-sandbox.io/ You can have a look where they specifically chose to force it https://github.com/signalapp/Signal-Desktop/commit/1ca0d821078286d5953cf0d598e6b97710f816ef https://github.com/signalapp/Signal-Desktop/commit/1ca0d8210...
- lynndotpy 2y ago
  You're right. It seems I am eating my words on that item, the `--no-sandbox` flag does seem to be on in most Linux installs. From context and search, it looks necessary for it to work on Debian. 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.
  - ementally 2y ago
    No worries, but it is a legitimate attack vector given that sandboxing on Linux sucks unlike Windows and macOS, so it is much needed. There's an issue open to provide a flatpak for the app. https://github.com/signalapp/Signal-Desktop/issues/1639 https://github.com/signalapp/Signal-Desktop/issues/1639