Another flaw in Signal desktop app leaks chats in plaintext

Post by tptacek » Fri, May 18, 2018, 1:20 AM UTC

confounded wrote: post #77

al_chemist wrote: post #44

Earlier quoted context omitted.

> don't use desktop secure messengers at all. Desktop applications are incredibly risky, far more so than iOS mobile apps are. It's risky to use an open source OS. If you are serious about security, use Android or iOS. Instead of direct ssl connection to XMPP server, it's much safer to send all your data with Google Cloud Messaging. /s Desktop computers are currently the most open sourced, least opaque, least spyware…

You have my upvote, but I imagine that tptacek means that iOS is very very well sandboxed, and has an extremely tight and well authenticated download and update system which is extremely difficult for a third party to monkey with. This is security via centralization and trusting a benevolent capitalist dictator. As long as your personal interests are aligned with interests of the benevolent capitalist's shareholders,…

Post by tedunangst » Fri, May 18, 2018, 1:27 AM UTC

tptacek wrote: post #71

tedunangst wrote: post #70

Earlier quoted context omitted.

No?

I think he forgot a /s. (Seriously).

Post by thaumasiotes » Fri, May 18, 2018, 1:35 AM UTC

rndgermandude wrote: post #57

pfg wrote: post #9

Earlier quoted context omitted.

As much as I'm not a fan of JavaScript, the problem is not so much the language but rather the choice of Electron and all that comes with it. Heck, even a web version or Chrome app would've successfully mitigated these attacks. Electron means you're one XSS away from remote code execution, and even worse, it makes it way harder to mitigate XSS through CSP (which Signal did utilize, but script-src 'self' can easily be…

While I agree that Electon offers a massive amount of footguns, neither Javascript nor Electon was the issue in this case. The issue was using innerHTML (or rather $.html()) with strings concatenated together from user input. Something you should never do. Could as well just call eval() directly on it, or pass the input to gcc, compile it and run the resulting binary. The Signal devs thought $.html() does some kind o…

Post by bigiain » Fri, May 18, 2018, 1:56 AM UTC

tormeh wrote: post #5

Maybe secure chat clients shouldn't be written in JavaScript or other languages that have excessive dynamicness? Signal seems to be written mostly in languages that are bad for security (significantly worse than the best alternatives). Maybe I'm just a language nerd without any clue about the trade-offs, but I trust the Wire software more. Note that this just applies to mobile clients and server - Wire, like Signal,…

Post by RVuRnvbM2e » Fri, May 18, 2018, 2:01 AM UTC

tptacek wrote: post #81

confounded wrote: post #77

Earlier quoted context omitted.

You have my upvote, but I imagine that tptacek means that iOS is very very well sandboxed, and has an extremely tight and well authenticated download and update system which is extremely difficult for a third party to monkey with. This is security via centralization and trusting a benevolent capitalist dictator. As long as your personal interests are aligned with interests of the benevolent capitalist's shareholders,…

I like open source software as much as most people on HN, and have worked with it for most of my career. But help me understand how a decentralized FOSS model gets ordinary lawyers, reporters, and congressional campaign staffers the level of security that iOS does? What are the mechanisms that assure safety for users? The closest I can come to seeing something like this work is a Chromebook, and Chromebooks are locke…