Hacker News new | ask | show | jobs
by CommentCard 3076 days ago
Signal has the perception of being more secure simply because it isn't owned by Facebook. I will never trust a Facebook server with private messages, despite both Signal and WhatsApp having the same security features on paper.
2 comments

Same with me.

I refuse to think Mark Zuckerberg

* bought it for north of USD10Bn

* made it free

* stopped all other monetization efforts (paid api gateways etc)

just to provide free messaging service to everyone.

I have two explanations:

* either he felt it was a threat to his future messenging monopoly

or

* (and this is already not a secret anymore) they wanted to feed the data into their already huge tracking and ad serving network.

Both of those are good enough reasons for me to leave as I care about healthy competition and my future privacy.

But maybe the biggest reason why is because they lied to me: they promised to be the service that provided a good messaging service in exchange for a modest fee. They were profitable and yet sold out.

Another possibility is that Zuckerberg's plans were destroyed (or at least delayed) by EU ruling[0], so he didn't get what actually expected.

0. https://www.theguardian.com/business/2017/may/18/facebook-fi...

?

You mean you agree he had an evil plan and it was thwarted?

"An evil plan" might be a bit of an exaggeration, but I think he might have expected more (read more private data or ad push) from WhatsApp users than he currently can get. Of course, that's just speculation, but as you've originally mentioned, it makes no business sense for Facebook to maintain a free messaging app with no strings attached.
> despite both Signal and WhatsApp having the same security features on paper.

Well, if you don't consider "being open source" a security feature...

Do you?

If you are going to audit something for its security features, you pretty much have to start with a disassembled binary, don't you?

Purely on the fundamentals, you could also start with the published source code, build it, and see whether the output matched the binary you're auditing.

In practice, that's unlikely to work, but it could work.

The problem isn't verifying that the source was used for some particular binary, the problem is that when you read source code, the names of functions and variables will impact your understanding of what they do. If you were to take the source code and remove all comments and randomize every symbol name, then you might be okay.
That's a problem, sure, but it doesn't suggest at all that "real security analysis" means starting with an obfuscated blob and reversing it. It suggests that you're better off doing both kinds of analysis. Variable names can lead your thoughts in certain directions and make it more difficult to see certain execution paths. Obfuscated blobs won't lead your thoughts much of anywhere they weren't already inclined to go -- but they make it much more difficult to see all execution paths.
Signal for Android does offer reproducible builds of the binary now. https://signal.org/blog/reproducible-android/
Not if it's open source and has reproducible builds...
Good luck not being influenced by comments (although they can be stripped) or by how things are named. I still think you are better off starting with a binary.
Which could still be done by compiling the source then disassembling it. You lose nothing by it being open source to begin with.