How Signal Beats WhatsApp
theintercept.com
theintercept.com
On top of that, I'm not going to get my parents to switch to the messaging app du jour. I'm going to hope that the one I use adopts good technology.
Maybe Signal is awesome. But privacy from law enforcement is not a killer feature. The US Government has substantial leverage over me in other ways. If it's come to the point that they want my communications, I've already lost.
What about the UK government? The GCHQ is one of the most aggressive and sophisticated signals intelligence agencies in the world.
What about the RU government? Or the Chinese government?
The reason most security folks speak of "nation state actors" in aggregate isn't to be euphemistic (initials: NSA), it's because "the only threat you might encounter online is your local government" isn't necessarily true.
To be clear, I don't want to turn this into a political discussion. I just wanted to point out that the scope is wider than your comment implied.
A big problem is that the threat to you exists, but is subtle: society gets worse when we allow this to happen to all those people that we would consider heroes years in the future but are deemed (sometimes by the letter of the law, sometimes not) criminals right now. Conformity for the forest by pruning the trees.
The bit about the free speech is a bit of a tangent, seeing as I can reasonably pick my battles, but the rest is fair.
I was under the impression that this had been reverted because it is "hard". Has that decision changed?
Signal being open source is still a very good argument in favour of it. It's also great that they're careful about not including features that could make it easy to shoot yourself in the foot (online backups). We can do without the whole "just trust them" dance.
Then it says Signal doesn't collect metadata, and stops there. I'm pretty willing to bet they're just as governed by NSLs as WhatsApp, and if legally required, can and will collect said metadata and hand it over.
The only way to not do so is to go the Lavabit route.
And Signal's "helpful" banner at the top that allows easy invitation of contacts will (rightly) be treated as spam by most of my contacts - these secure/encrypted chat apps keep coming and going, with some people saying "just use Whatsapp, it is now encrypted", others complaining that it is closed source, etc. I can't keep changing my recommendations every few months and expect my contacts to do the same. In fact, it is only through hn that I even heard of yet another protocol: https://matrix.org/.
Practically speaking, WhatsApp works best wrt security for me due to these network issues - essentially all of my Indian contacts have it for some reason, likely again some positive feedback loop due to network effects in India. And there is no such dominant app among my US contacts, hence I fall back to plain old SMS.
https://matrix.org/git/olm/about/
I've not audited their implementation, but at least that one design choice is sane.
IIRC there were some design changes between the early Axolotl ratchet and the Signal Protocol. If you're interested in using Olm, I would make "find out what the differences are and why" my first priority.
And I don't mean "I learned how to do textbook RSA in college", I mean more of, "Can tease a previously undiscovered cache-timing side-channel out of a crypto library". (For example, the recent libgcrypt advisories.)
If the words "padding oracle" or acronyms like AEAD sound strange and foreign, that person is not qualified to fill that role.
I would wager most developers lack the background to make a messaging service that is actually secure. (To anyone reading this: Please don't let this fact magnify any sense of impostor syndrome you may have. You're far from alone. Even the experts won't embark on this endeavor without peer review.)
https://github.com/WhisperSystems/libsignal-protocol-c
https://github.com/WhisperSystems/libsignal-protocol-java
More generally (i.e. not for messaging apps), libsodium is great for application-layer cryptography:
https://download.libsodium.org/doc/bindings_for_other_langua...
In terms of how it compares to Signal: we are still in alpha (although Olm now ships on the develop branch of matrix-js-sdk and dependencies), and so obviously Signal is infinitely more mature. However, we are getting the core ratchet publicly audited during July before we push all the E2E formally live, which should give a better idea of how reputable to consider it.
What does impact me is the userbase. I've tried, and generally failed, to get lots of friends using Signal. I get to use it with just the small subset that are privacy aware and techie.
Given they use the same protocol, it's a shame we can't message whatsapp or allo users. Yes it compromises my privacy compared to staying native, but less than having to install their whole app.
It'd be also great to have a desktop client for Linux. Even a simple CLI would do.
If those 2 things were fixed, it'd be an awesome messaging platform.
[1] https://github.com/WhisperSystems/Signal-Android/issues/1000
My biggest concern is that centralization necessarily leads to a central point of failure. While someone might be able to run their own fork of Signal in that case (kudos for making the server open source as well as the client!), nobody seems to be trying right now. Contrast that with email, XMPP, or HTTP, where millions of people have developed the operational skills necessary to do a modern deployment.
Your point about people moving between services instead of between providers seems true enough, in every space except for chat. People choose their chat provider based almost entirely on what their friends and colleagues use. Look at Facebook Messenger, Google Talk/Hangouts, even the ancient Yahoo Instant Messenger - all have significant user bases, despite not being number 1 technically in basically any category.
As for a truly federated applications protocol (with no implicit centralization), HTTP springs to mind. Despite your argument about HTTP being stuck in the 90s, a number of significant changes have occurred in this century. WebSockets, HTTP/2, and nearly ubiquitous TLS, among others, not to mention all the improvements in the browser space now that we finally have a sane standards process. And all of this is possible despite the fact that no single company has a majority of either server or client implementations. More importantly, HTTP is used in a far different way today than it ever was in the past. Instead of delivering pages of content over fast pipes to desktops, HTTP delivers rich web apps over flaky wireless connections to handheld computers - and the same protocol developed in the 80s has evolved nicely to serve both of these purposes.
Federation may not be the best answer for OWS, and it might not even be the best answer for the Signal community (today), but it is not necessarily the kiss of death for a project either.
I'm curious about signal but their with service just seems to hang for me.