Personally, I only want to send messages regarding harmless stuff. Being able to send my location in-line (or even share live like WeChat) is a feature I'd drop any privacy protection for.
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.
This is why the Signal team spends time working with other messengers. We want to help enable Signal Protocol in the products that everyone is already using (like WhatsApp), rather than expecting everyone to switch to our app.
> 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.
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.
I guess there is no point in arguing if you think this way. Paraphrasing Edward Snowden, if you don't work to protect privacy because the threat to YOU is not clear, you shouldn't work to protect free speech if you're not the one being silenced.
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.
Nothing has changed. The premise of that blog post is that we'd like to do better than ephemeral intersection requests using truncated hashes of contact identifiers, but that we don't believe it's currently possible to do better.
I don't know what you mean by "in the clear," but Signal has always done contact intersection with an ephemeral query of truncated hashes of phone numbers.
I feel like the metadata collection argument is overrated here. It's a nice promise, and it's not that I don't believe them, but at the end of the day it's just that: a promise. We've got messengers with E2E crypto because we don't want to just take someone's word that messages won't be read/intercepted, so the same logic should be applied to metadata: Either the protocol guarantees that metadata cannot be collected, or we should assume that it's being done.
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.
I think this is an important point. The article says WhatsApp doesn't collect metadata as normal course, but it can and will where legally required.
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.
Exactly. I have Signal installed, but none of my contacts have it installed on their phones.
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.
The premise of the article --- and it's a good premise --- is that the secure chat applications you should consider are those that implement Signal Protocol. Matrix does not.
correct; Matrix doesn't implement Signal Protocol. We use the Olm ratchet as a 1:1 ratchet which is an independent implementation of the Double Ratchet (aka the Ratchet formally known as Axolotl), and have added our own group ratchet called Megolm to handle the semantics required for Matrix.
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.
That's not an undertaking that should be taken lightly. At minimum, you should have a team wherein one of the people making the final design decisions is a cryptography expert.
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.)
to be clear, I was hoping to build it casually on top of a protocol or library. I would not be planning on rolling my own crypto or anything like that. I want a feature of my application to be encrypted chat which given the large availability or apps & libraries, I was hoping could be more of an integration than a build out.
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.
Ah ok I'm not necessarily so much interested in using it, but have been looking into the details of the signal ratchet recently, and was wondering what the specific changes / rationale..
I love Signal and they're responsive to requests or bug reports in a way that Google or Whatsapp can never be, and it seems, don't want to. I don't care if it's missing a few features. Most of the features added to messaging are pointless fluff anyway. So what they're 3 people, when I reported an unusual bug it was fixed in a couple of days. Try that with Google.
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.
I dislike a bit how they have ignored community requests to support alternative transport systems to Google Cloud Messaging [1]. This has even led to a fork [2].
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.
As a counterpoint: I reported an unusual bug months ago and it still isn't fixed. Instead they gave me the usual "try turning it on and off again" baloney and then began ignoring the issue.
Though the argument is that it's closed source, there's a level of trust I have for Wickr and team. There's even less meta involved with Wickr since no phone number is collected and the app forensically deletes messages. Nico Sell has a pretty awesome reputation of standing up for privacy.
Thanks for the well-reasoned and well-explained post. I still instinctively disagree, but I need to go make a cup of tea and ruminate a bit before I can fully explain why.
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.
It looks like Conversations has implemented the Axolotl ratchet for XMPP as "OMEMO". I need to do more research to see how I can get support for that on all of my devices.
Telegram uses homegrown crypto with known weaknesses[1] and doesn't do end-to-end encryption by default (your messages are stored on their server in plain text).
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.