Signal is open source. But you have to trust the OS it runs on...

And even if you trust the OS, you have no idea what is going on on the phone's baseband processor: https://en.m.wikipedia.org/wiki/Baseband_processor

One has to assume that all are back-doored. Mobile phones are inherently not trustable.

Same goes for all major firewall vendors. If you going to hack one of them as a nation state, then you're going to do all of them.

There is at least one project that seeks to mitigate the threat posed by baseband processors having DMA, Neo900: http://neo900.org/faq#privacy

Even if you trust the OS and the baseband, you have to trust that the federated server for Signal (OpenWhisper, Cyanogen, etc) isn't storing contact discovery requests.

And the hardware the OS runs on... Intel and others are now embedding "management" features at a very low level.

You're still secure if you use https. If neither your computer nor the host you're connecting to has been tampered with, then you're safe irrespective of what's happening between.

I get where you're coming from and I want to agree with you but...

While that used to be true, based upon recent history we, unfortunately, can't blindly trust HTTPS to always be "secure" 100% of the time anymore -- whether due to things like Heartbleed, fake certs signed by a root CA, protocol attacks, or some other vulnerability that hasn't even been discovered yet.

Well, what if the host you're connecting to is a Juniper firewall?

Yeah, because illegitimate / spoofed certificates will never happen...

I think we're well on our way to a point where certificates can be mostly trusted. Of course certs can be stolen, but I would bet that "spoofed" certificates will soon be an occurrence of the past.

With certificate transparency, at least we'll know about it - afterwards, at least.

Well, afterwards, if the attack stops (software does not need to stop) in a timeframe short enough for your computer to no clear its history.

Many https sites use RC4, I wouldn't be so sure.

Then use a browser that rejects RC4 (like latest Chrome).

The private key is used to negotiate a session key, which is then used as the symmetric key for RC4 or whatever stream or block cipher you are using. Those session keys are ephemeral and per-session, so leaking them is only a problem for those sessions.

(Also, since it's a stream cipher, it can't use the same key ever again, else you can xor those ciphertexts to get 2 xored plaintexts, which are much easier to crack.)

It's sad but comments like this made me turn away from language as a reliable means of communication. I used to believe anything I'd read. But, having become aware of trolls and worse, those days are gone. Not only English, but Japanese and who knows which other languages are untrustworthy.

I'm not sure what you are trying to communicate.

Trust is something delicate which works best by using face to face communication.

So it's ok not to trust everything you read.

But this story is about private communication not being as private as thought.