
Why I won't recommend Signal anymore - maglavaitss
https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore/
======
zigzigzag
Like a lot of crypto-puritanism it is rather mixed up. He says he recommended
Signal because it was easy to use (more consumer friendly I guess) and secure,
then says he wouldn't have gone in the direction of making it easier to use
and criticises the things that make it user friendly, like using phone numbers
instead of usernames.

He says he thinks the protocol is secure, then says he doesn't want it to use
GCM because it routes messages via Google who he doesn't trust (fixing that is
the point of the encryption) and then talks about an attack that'd apply to
any app regardless of whether it used GCM or not.

He finishes with a call to action: _" We as a community need to come up with a
viable solution and alternative to Signal that is easy to use and that does in
fact respect people’s choices ... this tool should not have dependencies on
corporate infrastructure"_

But like a lot of armchair moralising, he isn't willing to debate the hard
choices that go into building successful software. He says it should "respect
people's choices" as if Signal is built by people who are disrespectful, he
says it should not have dependencies on "corporate infrastructure" as if
volunteer run datacenters actually exist, and then says his motivation is
avoided paywalls, ignoring that both Signal and WhatsApp are free.

It reads like a collection of talking points rather than a coherent argument.

Signal is unusual because it combines cutting edge cryptography with consumer
friendliness and is actually successful. It's pragmatic, not ideological.
Crypto-warriors have a long history of producing secure software that nobody
uses and then blaming the general public for not getting it; this sort of blog
post is just a continuation of this decades long trend.

~~~
tptacek
I agree overwhelmingly with what you wrote, except that I want to point out
that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a
cryptographer, and if you asked a panel of 10 cryptographic engineers what
messaging system they'd recommend, 9 of them would say "Signal".

The 10th wants you to use something else because they're working on an attack
for that "something else", and want their paper to be splashier when it's
released. :)

When reading critiques of messaging software, keep in mind that messaging is a
fucking midnight back-alley knife fight of a market. For whatever reason --- I
think because (a) basic chat software is pretty easy to write, with a near-
hello- world payoff similar to, say, blog software for Ruby on Rails and (b)
because there have been multi-billion-dollar acquisitions of messaging tools
--- there are a _lot_ of different messaging products. Messaging is a network-
effect market, so all the different vendors are fighting for users.

I don't think Signal has sockpuppets (it's just not their style), but I _know_
several other "secure" messaging applications do.

~~~
moxie
I think these types of posts are also the inevitable result of people
overestimating our organizational capacity based on whatever limited success
Signal and Signal Protocol have had. It could be that the author imagines me
sitting in a glass skyscraper all day, drinking out of champagne flutes,
watching over an enormous engineering team as they add support for animated
GIF search as an explicit fuck you to people with serious needs.

I invite those who have opinions about Signal to start by getting involved in
the project. To my knowledge the author of this blog post has never submitted
a PR, issue, or discussion post to any of our repositories or forums. Many of
these points are things that we would like to address, and we could use the
help. The day to day reality of developing apps like these is a lot of work.

To provide some color on a few of these:

> Dependency on Google Cloud Messaging

To clarify this for casual readers, no data at all is transmitted over GCM.
GCM is only used as a push event to tell the Signal Android client to wake up
and connect to the Signal server to retrieve messages from the queue if the
app isn't in the foreground.

This is pretty fundamentally just how Android works. However, people who want
to use Google's OS without any Google services flash custom ROMs onto their
devices that are missing this dependency.

I have said many times that I have no problem with supporting these custom
ROMs. But I would like someone from that community to submit the PR: "I would
consider a clean, well written, and well tested PR for websocket-only support
in Signal. I expect it to have high battery consumption and an unreliable user
experience, but would be fine with it if it comes with a warning and only runs
in the absence of play services."

Nobody has done it.

> Your contact list is not private

First, on Android 6+ you can just disable the contacts permission and
everything works (although you obviously won't see your contact names).

However, we also spend a lot of time thinking about this class of problems, as
well as metadata in general. Right now things are playing out alright for one
specific class of attack:

[https://whispersystems.org/bigbrother/eastern-virginia-
grand...](https://whispersystems.org/bigbrother/eastern-virginia-grand-jury/)

We'd obviously like to do even better. The nice thing about having a
centralized service is that we can eventually take steps in this direction.
People seem to equate federation with meta-data hiding for reasons I've never
totally understood, but I think serious metadata protection is going to
require new protocols and new techniques, so we're much more likely to see
major progress in centralized rather than distributed environments (in the
same way that Signal Protocol is now on over two billion devices, but we're
unlikely to ever see even basic large scale email end to end encryption).

> Lack of federation

I've tried to write about why I don't feel like this is going to be a part of
our future here: [https://whispersystems.org/blog/the-ecosystem-is-
moving/](https://whispersystems.org/blog/the-ecosystem-is-moving/)

However, I would love it if someone proved me wrong. The Signal clients and
server already support federation, so there shouldn't be any technical hurdles
stopping the people who are really into federation from using our software to
start their own federated network that demonstrates the viability of their
ideas.

If anyone needs help doing that, let me know. I'd be happy to help.

~~~
mirimir
Thanks for the clarifications.

> First, on Android 6+ you can just disable the contacts permission and
> everything works (although you obviously won't see your contact names).

This is very good.

> However, we also spend a lot of time thinking about this class of problems,
> as well as metadata in general. Right now things are playing out alright for
> one specific class of attack: [federal subpoena]

Good, so Open Whisper Systems has no metadata. Do any third parties retain
metadata about Signal messages?

There's also the issue of mobile numbers. I get that more-or-less anonymous
numbers are doable. But arguably, most Signal users don't have anonymous
numbers. However, maybe this is a non-issue, if the only data available are
"the date and time a user registered with Signal and the last date of a user's
connectivity to the Signal service". Is that it?

~~~
exo762
> Good, so Open Whisper Systems has no metadata. Do any third parties retain
> metadata about Signal messages?

I'll try to answer to the best of my knowledge (I'm not associated with
project, I'm just a happy customer).

Does your ISP know that you are communicating with Signal servers? Yes, IP
addresses.

Does it know to whom you are sending messages? No.

Does Google know you are using Signal? Yes.

Does it know whom of your contacts use Signal? Yes, because they have a full
list of your contacts and they know if someone has installed Signal.

Does Google know you've sent a message? No.

Does Google know that you are receiving a message? Sometimes, because Signal
servers ping your device via GCM with "wake up".

Does Google knows who from your contact list send this message? No, unless you
have only one contact who uses Signal.

Can Google infer from pings who is communicating with whom? Yes, although
pings are needed only if app has disconnected from server, and this severely
limits usefulness of this technique.

Where else may any metadata coming from usage of Signal be? Nowhere.

As for Google having your contact list... Take a look into Flock.

~~~
mirimir
Thanks :)

I get that Signal is probably the best option for smartphones. And that maybe
its vulnerabilities are only relevant for "TAO targets". But the problem is
that "TAO targets" is in rapid flux, given developments in automation and AI.
So arguably, more and more journalists and dissidents are becoming vulnerable.

And there's the fundamental insecurity of devices with cellular-radio
connectivity, and operating systems that users can't control and lock down.
Signal can do nothing about that. Even something as simple as reliably
obscuring identity in connections to Signal servers is nontrivial.

~~~
exo762
> But the problem is that "TAO targets" is in rapid flux, given developments
> in automation and AI.

You are implying that cost of TAO consists mostly of labor costs. Which is
false. NSA and friends are not really limited by money. They are limited by
amount of unpatched software vulnerabilities. Every use of vulnerability in
the wild is a chance of revealing it to world and losing it. Snowden docs
reveal the existence of automated software which evaluates chance of
vulnerability being revealed by attack. XKeyScore or one of related pieces,
AFAIR.

------
tptacek
The author of this post believes that by making a stand over Signal policies
he doesn't like (the superficial GCM dep, the OWS-only server policy, the
contact list discovery system), something more like LibreSignal will grow to
take Signal's place.

The author is wrong. LibreSignal won't replace Signal. Something like Telegram
will: an "open source" messaging system with inferior cryptography, "opt-in"
end-to-end messaging, a long-term dependency on the telephone system for
authentication, and a far "cuddlier" personality with its users and, more
importantly, with people from the app development community (like the author).
Telegram will continue to gain adoption, because sexy beats sound in every
end-user match up. Signal is the closest thing sound cryptography has to a
palatable solution for end users.

Iran has already compromised Telegram users, because it systemically trades
security off for user adoption. They'll get more of them, and people will hang
from cranes as a result.

It's not wrong to criticize Signal. Signal does things I don't love, too! But
we should be clear-eyed about the market.

~~~
sandervenema
Hi, author here. I don't think LibreSignal or indeed Signal will ever be the
dominant mobile messenger out there. There's simply a lot of inertia to fight
against. It's the same reason why it's hard to convince e.g. Facebook friends
to move to a different social network, why Google+ failed, etc. Whenever the
social aspect gets involved, companies can very easily create lock-in by being
early, and then the social aspect will prevent the majority of people from
considering changing, because 'it works'.

I never said that LibreSignal will replace Signal, and frankly, LibreSignal
itself is not the solution either. But maybe LibreSignal will be the catalyst
to a better solution.

We all want to prevent people hanging from cranes, but crypto alone does not
equal privacy, does not keep you safe, especially not in those countries,
where rubber hose cryptanalysis
([https://xkcd.com/538/](https://xkcd.com/538/)) is much more common. In those
dangerous situations/countries, good operational security practices are better
to avoid detection/suspicion than using any 'magic' crypto messaging app.

~~~
tptacek
You don't understand what I'm saying. I agree that crypto alone doesn't equal
privacy --- it's table stakes. Clearly: it does not follow from that
observation that crypto doesn't matter. If you cannot _at least be
cryptographically secure_ , the rest of what you do doesn't matter.

We now have two examples --- CryptoCat and Telegram --- of "secure messaging"
systems being used by governments as a way of hunting down activists. Why do
we need more? Can't the question be settled now?

As gently as I can, I'm going to push a little further. I poked around your
site a little to get a sense of where you're coming from. Your post today
opens up like this:

 _One of the things I do is cryptography and infosec training for
investigative journalists who have a need to keep either their sources and
communications confidential so they can more safely do their work in the
public interest._

Can I ask what your qualifications are in training journalists in keeping
their communications secure? Investigative journalists working in hostile
regimes, even in smaller countries, are facing adversaries that are better
funded than almost any other imaginable threat. Cryptography is incredibly
hard. Elsewhere on the thread, you said "I'm not a cryptographer". Neither am
I! I've spent the better part of 10 years getting decent at breaking
cryptosystems for clients, and I still refuse to do privacy implementation
work, because I'm simply not up to the challenge. Are you sure you are?

~~~
sandervenema
Regarding qualifications: I spent years building secure technology
(publication platforms, websites) for whistleblowers including Ed Snowden
himself (I built his official website
([https://edwardsnowden.com](https://edwardsnowden.com)) for the Courage
Foundation (his official defence fund) plus the tech behind it that supports
it. This allows our editors to submit anonymously to the site through the Tor
network.

I used cryptographic software as an end-user for many years, like GPG for
instance, and agree that it's hard, and we need to train people to use correct
security habits (infosec and opsec), to minimise exposure to hostile elements.

I've tought at cryptoparties and other events, I have spoken to many
intelligence whistleblowers, some of which I consider to be close friends, and
they've told me about some of the techniques used on the national intelligence
agency level and how wrong use of crypto and general bad operational security
practices can expose you. So while I'm not a trained cryptographer, and do not
claim to be, I have extensive experience not only building secure software,
but also, thanks to whistleblowers know about some of the ins and outs of the
intelligence industry re crypto and surveillance.

~~~
sandervenema
One thing I wanted to add, regarding the tech: of course I do that in
cooperation with other people some of who are indeed trained cryptographers.

~~~
tptacek
Who are those people? There aren't many of them, in, like, the world.

~~~
sandervenema
True, they are rare. On another unrelated project I'm working together with
Bill Binney, the cryptographer who wrote ThinThread at NSA. That's all I can
currently say about it.

------
clumsysmurf
Unfortunately, Google has made it (almost) impossible to wake up the phone via
some external event without using its proprietary GCM. Even though GCM is not
part of AOSP, it has unique status on the platform that can't easily be
replicated (without recompiling the kernel, etc like the article mentions).

Before the days of doze mode & other battery optimizations, you could just
listen & block on a socket, then let the phone go to sleep. Incoming 3G
packets would wake up the phone, you grab a wakelock, then start doing things.
From what I remember, at least a while ago Facebook Messenger did this using
MQTT. But this is not possible any more.

~~~
Mathnerd314
Kind of tangential, but GCM is deprecated and you're supposed to use Firebase
Cloud Messaging now: [https://firebase.google.com/docs/cloud-
messaging/](https://firebase.google.com/docs/cloud-messaging/)

It's still just a JAR (no native components), so AFAICT there's no technical
reason someone else couldn't do a similar thing with their own servers.

~~~
kuschku
> It's just a JAR (no native components)

I’ve reversed it, and rebuilt an alternative

The jar you include actually opens just an IPC channel to the Google Play
Services framework, which runs with system permissions, and handles the actual
stuff.

You can’t implement your own FCM without having root access on EVERY Android
phone out there.

~~~
Mathnerd314
Maybe not. Although there's this guy: [https://eladnava.com/pushy-a-new-
alternative-to-google-cloud...](https://eladnava.com/pushy-a-new-alternative-
to-google-cloud-messaging/), it seems like his library doesn't work very well
after Nougat.

~~~
kuschku
From Android 6 on, Doze just terminates apps running in background after a
while. The only network access that is allowed is GCM.

Which causes the entire issue.

I wrote a complaint to the EU privacy official responsible for them and the EU
antitrust committee.

~~~
codethief
That's an excellent idea! Do you have a blog or something where you're going
to post when (if) you get a response?

------
SamWhited
I highly recommend Conversations (disclaimer: I've worked on it in the past,
although I'm not a project "member" per say):
[https://conversations.im/](https://conversations.im/)

It's open source, uses a federated, open protocol, and can do multiple types
of encryption including OTR and OMEMO (an XMPP wire format that uses the
Axolotl ratched devised for signal). It does not do VoIP, so it would just be
for chat (although there is a large bounty on Jingle-based voip support open).
It has also had a public security audit, and is designed to be white labeled
so you can tweak a few variables in the source and build your own hardended
version or encrypted-only version, etc.

~~~
giancarlostoro
Curious for next time I evaluate XMPP is there a list of servers recommended
by the Conversations team that people could install themselves? My issue with
XMPP is that on the same system I have at DigitalOcean where I could run: an
IRC server, a Web Server, and a Mumble Server and extra goodies all together
in one box, I couldn't effectively run a XMPP server that would stay up (it
would crash). I would of kept at XMPP had I found a decent memory efficient
server that didn't merely crash.

~~~
majewsky
I have a virtual server (1 CPU + 1 GiB RAM) running nginx, murmur and Prosody.
free(1) reports 80 MiB used memory, thereof 10 MiB for Prosody. (I just have
one active account, though: myself.)

So unless you're planning on hosting hundreds or thousands of users, you
should be fine IMO.

~~~
giancarlostoro
I had not even 3 users... I was running a Java one, looks like Prosody is
worth it's salt. Does it support E2E and other features that Conversations
supports? :)

Edit:

I was running it on a DigitalOcean box with only 512MB of ram at the time,
which I found a bit silly that I would come back and the server was down, but
it was a different XMPP server than Prosody.

~~~
catdog
You probably used Openfire, known to be a memory hog and a bit unstable.
Simply go for prosody and you should be fine (ejabberd should also be OK).
Some newer XEPs which you may want to have with Conversations are not
supported OOTB in prosody (yet) but there are plugins distributed separately
[1][2].

[1] [https://modules.prosody.im/](https://modules.prosody.im/) [2]
[https://prosody.im/doc/installing_modules](https://prosody.im/doc/installing_modules)

~~~
giancarlostoro
Yes that was the culprit! OpenFire sounds like it... I wanted something simple
to setup, without too many terminal incantations. Thanks for the information,
it's invaluable.

------
SapphireSun
Essentially this guy is saying, Signal is secure, it's mostly easy to use
(with the exception of multiple phone numbers), and the only alternative he
mentioned is a half broken clone. Is he seriously going to stop recommending
it to people whose lives depend on secure communications because of some
abstruse ideological point? In any case, Moxie's position is a reasonable one
even though there are some arguments for federation.

While my current phone doesn't support Signal, once I get a new one I will
continue to use it _.

_ You might opine that allowing Signal clones would allow me to use the app,
but they would almost certainly be maintained by people who aren't really
crypto experts, and so it's better to operate as though I am broadcasting in
cleartext than to pretend that I'm not and get burned.

~~~
kuschku
The biggest argument is that there is little of a difference between Signal
and Telegram or Signal and WhatsApp for the user if they are forced to use the
official servers, and those servers get to store their entire social graph.

~~~
SapphireSun
Here's what Moxie said about this issue:
[https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

~~~
wtbob
And here's my write-up of how a private set-intersection protocol could be
used to enable users to securely swap contacts:
[https://news.ycombinator.com/item?id=11289223](https://news.ycombinator.com/item?id=11289223)

It's a solved problem, but Signal doesn't implement it.

~~~
bascule
The protocol you describe is a synchronous online protocol where Alice and Bob
have to be online at the same time (and if they're doing this at Charlie's
behest, so does Charlie). Signal is designed for asynchronous communication
where both participants don't have to be online to discover each other or send
each other message.

Also, how does this protocol even help? What's the use case? It allows
participants to discover mutual contacts, but what then? Do we use Bob as a
web-of-trust style introducer? What if Alice doesn't even want to talk to
Charlie? Do we do this for all the friends Alice has in common with Bob? Do we
do this for all the friends Alice has in common with everyone? Does Charlie
initiate the process, only to have it only work if all three of them are
online at the same time? Who kicks it off and why, and what would the user
experience be?

You end your last post with "So, problem solved" but I'm not sure this
protocol even solves any practical problems for the Signal use case, and seems
like a mere first step of solving a much more complicated problem of actually
trying to turn this into a useful feature with good UX.

~~~
wtbob
> The protocol you describe is a synchronous online protocol where Alice and
> Bob have to be online at the same time (and if they're doing this at
> Charlie's behest, so does Charlie).

They don't actually have to be _online_ at the same time (and they don't care
about whether Charlie is online or not: it's a pairwise protocol): they just
to be able to send and receive one another messages, and to store state.
Fortunately the former is some Signal's quite good at, and storing state is
something that phone hard drives are quite good at.

> Also, how does this protocol even help? What's the use case? It allows
> participants to discover mutual contacts, but what then? Do we use Bob as a
> web-of-trust style introducer? What if Alice doesn't even want to talk to
> Charlie? Do we do this for all the friends Alice has in common with Bob? Do
> we do this for all the friends Alice has in common with everyone?

It's the exact same use case as Signal's existing contact-discovery code, only
private: it enables Alice & Bob to share information about a mutual
acquaintance, e.g. Charlie. This might be used to share Charlie's key ID, in a
trust on first use style. Note that this is no less secure than everyone
everywhere trusting Open Whisper Systems on first use.

The idea is that when one starts using Signal, one exchanges keys in some out-
of-band mechanism (NFC is a likely candidate) with an acquaintance, and then
from that person get keys of mutual acquaintances, and from then others, and
so on and so forth. Whenever you add a new acquaintance, one can reiterate the
same protocol with all previous acquaintances (it's amenable to batching, too,
which is nice) in order to propagate that information.

It _may_ have some interesting uses in a certificate transparency sense, but I
don't know about that.

> You end your last post with "So, problem solved" but I'm not sure this
> protocol even solves any practical problems for the Signal use case

It solves the exact same problems the Signal contact-discovery protocol
solves, without actually revealing all one's contacts to OWS. That's all. If
it did nothing more than that, it would be a good thing.

~~~
bascule
> It solves the exact same problems the Signal contact-discovery protocol
> solves, without actually revealing all one's contacts to OWS.

Except it doesn't. If you share your contacts with Signal, it can tell you
which ones are on Signal.

If Alice shares her contacts with Bob, she may discover some contacts she has
in common with Bob, but not necessarily which ones are Signal users. Perhaps
Bob has talked to Charlie some time in the past using Signal, but perhaps not.

So if we run this chatty, online, synchronous protocol with each of your
contacts you already know are on Signal who happen to be online at a given
time (which will be a subset of all your contacts), you may-or-may-not
discover some of your contacts use Signal.

In my previous post I was really asking about the user experience angle, which
you didn't respond to at all, so rather than asking a question, let me simply
say: I think this feature (at least in as much as I can conceive of it being
used) would provide a poor user experience.

~~~
wtbob
> If Alice shares her contacts with Bob, she may discover some contacts she
> has in common with Bob, but not necessarily which ones are Signal users.
> Perhaps Bob has talked to Charlie some time in the past using Signal, but
> perhaps not.

The contacts which would be shared would be _Signal_ contacts, identified by
some public identifier like their phone number (which is the only public
identifier Signal currently supports; it could easily be extended to support
other identifiers though).

Yes, it won't reveal to Alice that her friend Etta is also using Signal, if
Etta and Alice don't have anyone in common. That's part of the privacy-
preserving feature which prevents _Signal_ from knowing who's using it, and
whom everyone knows.

Given the small-world phenomenon, the odds are that one will very quickly add
most folks one knows about, and the others can be added manually.

> So if we run this chatty, online, synchronous protocol

It's not chatty: the exchanges _are_ large, in order to protect privacy, but
they are also rare, and are not ongoing. Whenever you add a new contact, you
re-initiate the protocol with your pre-existing contacts, that's all.

It's not online: as I indicated before all that's required is for each party
to send & receive messages, and have some state.

It's synchronous, I'll grant, but only in the trivial sense that one party
acts, then at some point in the future the other party acts. It certainly
_doesn 't_ require both parties to be online at any point.

> In my previous post I was really asking about the user experience angle,
> which you didn't respond to at all, so rather than asking a question, let me
> simply say: I think this feature (at least in as much as I can conceive of
> it being used) would provide a poor user experience.

I think that the user experience would be identical to the current Signal UX:
from time to time one's phone would buzz and indicate that one of one's
friends uses Signal. If one wanted to, one could add a contact in person, e.g.
through NFC or QR codes or whatever.

You seem very invested in hating this idea; you might ask why _I 'm_ so
invested in it. Very simply, Signal is a tool for secure communication, but it
requires that end users reveal every person they've ever communicated with to
OWS.

~~~
bascule
I guess you still don't understand where this falls down yet:

> The contacts which would be shared would be Signal contacts, identified by
> some public identifier like their phone number

If Alice and Bob are just comparing their directories of already-known Signal
contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob,
and Charlie are already each other's contacts!

So this protocol can only help people discover contacts they are not yet aware
are Signal users. That would involve comparing their full set of on-device
contacts and sharing mappings of which one of those are within the subset of
known Signal contacts.

> You seem very invested in hating this idea

I would continue trying to give you what I thought were constructive technical
criticisms, but apparently you interpret that as me being "invested in hating"
the idea.

It's more like I'm invested in providing good user experiences for security
tools, which often involves starting with the user experience you want to
provide and working backward, not starting with a cryptographic algorithm and
trying to bolt-on a good user experience.

The latter is how we wound up with a pervasive ecosystem of unusable security
tools that Signal is a refreshing departure from.

You are starting with a protocol, not thinking about the user experience, and
declaring it a "solved problem". I'm not even convinced this protocol is the
right tool for the job.

~~~
wtbob
> If Alice and Bob are just comparing their directories of already-known
> Signal contacts, there's nothing for a discovery protocol to accomplish:
> Alice, Bob, and Charlie are already each other's contacts!

No, they are sharing (tel:+12025551212
signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca)
pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then
— since they both know one another and both know Charlie — feel good about
sharing with one another what Charlie's Signal ID is.

> So this protocol can only help people discover contacts they are not yet
> aware are Signal users.

Which is _exactly what Signal 's current contact-sharing protocols does_, in
addition to helping Signal discover all of one's contacts.

> I would continue trying to give you what I thought were constructive
> technical criticisms, but apparently you interpret that as me being
> "invested in hating" the idea.

I will give you the benefit of the doubt and assume that your repeated
failures to understand the protocol and its requirements are due to by own
poor explanations, and further that you actually intend to be constructive.

> It's more like I'm invested in providing good user experiences for security
> tools, which often involves starting with the user experience you want to
> provide and working backward, not starting with a cryptographic algorithm
> and trying to bolt-on a good user experience.

I'm starting with a principle, not a protocol. That principal is that: online
service providers must know the absolute minimum amount of information to do
their jobs. Ideally, instant messaging would use some form of private
information retrieval protocol so that server couldn't know who is talking to
whom. Given Signal's current architecture, it must know to whom one _is_
talking; there's no reason for it to also know everyone to whom one _could_ be
talking.

> The latter is how we wound up with a pervasive ecosystem of unusable
> security tools that Signal is a refreshing departure from.

Is it better to be usable but insecure than unusable but secure? I think the
answer is mu: a product must be both usable and secure. Granted, security is
always in the context of some threat, but it should be possible for users to
intuitively grasp the security context.

> You are starting with a protocol, not thinking about the user experience

So, what do _you_ think the user experience of contact discovery should be?
I've already demonstrated that my proposal has an identical experience to
Signal's, with the exception that one must manually register contacts not know
to one of one's contacts. How would you implement contact sharing without
giving OWS access to everyone's address book everywhere?

------
chrismartin
Signal may not transmit any payload via Google Cloud Messaging, but Signal's
requirement to run Google Play Services compromises the user's privacy in ways
that have nothing to do with Signal. If you run Play Services then you have a
device which provides your communications metadata, whereabouts, and device
usage habits to Google.

I don't trust Google with this information and don't want to carry such a
device, but a handful of friends and family use Signal, so I must choose
between easy/secure communication with them, and reducing my exposure to
corporate surveillance.

Signal may be "pragmatic" among the current choices (just like the project's
decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves
criticism for:

1\. Tying secure communication to running what amounts to Google's spyware on
your device

2\. Offering no alternative for privacy-conscious users

3\. Showing hostility to those trying to introduce such an alternative to the
project

I think those dismissing these concerns as "crypto-puritanism" will be on the
wrong side of history.

~~~
haffenloher
> 3\. Showing hostility to those trying to introduce such an alternative to
> the project

Quite the contrary, they're actively asking people to contribute code for an
alternative push mechanism [1][2]:

" _I would consider a clean, well written, and well tested PR for websocket-
only support in Signal. I expect it to have high battery consumption and an
unreliable user experience, but would be fine with it if it comes with a
warning and only runs in the absence of play services._ "

[1]
[https://github.com/LibreSignal/LibreSignal/issues/37#issueco...](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-226646872)
[2]
[https://news.ycombinator.com/item?id=12883410](https://news.ycombinator.com/item?id=12883410)

------
reacharavindh
This. I didn't know much of the insides of Signal. But, When WhatsApp decide
to go in bed with FB to share my contacts and usage, one of the alternatives I
explored was Signal. Threw it out the moment it asked for ownership of my
contacts (no way to opt out). I for one am not going to trust a guy's pinky
promise to be good with my contacts and meta-data.

If I'm going to give up the convenience of reaching anybody by WhatsApp, it is
going to be at least worth it in the sense of privacy.

Still hoping for a GNU project that garners enough interest to be technically
strong, and used universally. One can dream.

~~~
Joeboy
I doubt you'd want to use it if it _didn 't_ use your contacts, though. Not
many people are prepared to deal with a whole separate set of contact ids for
the sake of a small amount of arguable extra privacy.

~~~
codedokode
There could be two separate versions, one for paranoid users, one for those
who don't care. The number of permissions Signal app requires is scary. It
gets almost full control over your phone including reading SMS messages.

~~~
majewsky
> The number of permissions Signal app requires is scary.

This is exactly why I'm shying back from recommending Signal to my family. I
taught them that the equation "permissions = bad" generally holds, so Signal
would look like spyware to them, even if every single permission turns out to
be justified for some reason.

------
codewiz

      "Also, there’s the issue of integrity. Google is still
      cooperating with the NSA and other intelligence agencies.
      PRISM is also still a thing."
    

What's this based on? Google immediately denied any association with the NSA
and PRISM:

[https://googleblog.blogspot.com/2013/06/what.html](https://googleblog.blogspot.com/2013/06/what.html)

Google’s chief legal officer claimed that collection was being done without
Google's consent:

[http://www.irishtimes.com/news/technology/google-outraged-
at...](http://www.irishtimes.com/news/technology/google-outraged-at-nsa-
interception-claims-1.1579245)

Evidence leaked by Edward Snowden also points in the direction of illegal
infiltration of Google's private network without Google's consent:

[https://www.washingtonpost.com/world/national-
security/nsa-i...](https://www.washingtonpost.com/world/national-security/nsa-
infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-
say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html)

~~~
sandervenema
On this: [https://wikileaks.org/Op-ed-Google-and-the-NSA-
Who-s.html](https://wikileaks.org/Op-ed-Google-and-the-NSA-Who-s.html)

there are links on that page that point out multiple e-mails from the STRATFOR
leaks and other files that point to Google being deeply embedded with the U.S.
security apparatus.

Also: [https://www.theguardian.com/world/2013/aug/23/nsa-prism-
cost...](https://www.theguardian.com/world/2013/aug/23/nsa-prism-costs-tech-
companies-paid)

~~~
sandervenema
And Google became a PRISM partner in 2009, as the slides here from the Snowden
collection prove:
[https://search.edwardsnowden.com/docs/PRISMUS-984XNOverview2...](https://search.edwardsnowden.com/docs/PRISMUS-984XNOverview2013-06-06nsadocs)

~~~
codewiz

      And Google became a PRISM partner in 2009,
      as the slides here from the Snowden collection prove
    

Read those slides more carefully: they say that collection from Google began
on 1/14/09, not that Google became a willful partner of the PRISM program.

~~~
sandervenema
As the previous links from STRATFOR etc. prove, Google is deeply embedded in
the security/intelligence apparatus. That part is definitely willing and
beneficial to both parties. Of course, they're going to make changes and issue
statements to the contrary regarding PRISM, because that would lose them
customers.

This is also an interesting read, albeit a bit long:
[https://wikileaks.org/google-is-not-what-it-
seems/](https://wikileaks.org/google-is-not-what-it-seems/)

Google continues to coast on the goodwill of its "don't be evil" doublespeak,
as Mr. Assange puts it. There's no reason to trust them now.

~~~
bitmapbrother
You've presented no proof whatsoever. All you've done is make unsubstantiated
allegations.

------
EugeneOZ
Any messenger, tied to phone number, is not safe. possible attacks are: 1)
create copy of sim-card; 2) force mobile operator to intercept password-code,
sent to your number, and "restore" password this way. It may sound ridiculous
for you, but in Russia it's reality (both vectors), it's real cases from life.
And when user really need safe messenger, all of them are too careless to
implement really safe way of messaging. And if you think these vectors are not
possible in your country - be sure, we were thinking the same way.

~~~
trimbo
This is why there is a fingerprint ("Safety Numbers" in Signal), and a warning
on every message when that fingerprint changes.

~~~
codedokode
Warning still does not fully prevent the attack. The attacker can still access
the account and obtain the data stored at a server (like contact list if it is
stored there).

~~~
majewsky
> like contact list if it is stored there

The only thing that we know they store is the creation timestamp and last-seen
timestamp for each account: [http://arstechnica.com/tech-policy/2016/10/fbi-
demands-signa...](http://arstechnica.com/tech-policy/2016/10/fbi-demands-
signal-user-data-but-theres-not-much-to-hand-over/)

Reading over the article again, though, it neither confirms nor denies where
these timestamps are the _only_ thing stored about an account. They explain
these are the only data matching the concrete subpoena they received.

------
heavenlyhash
EDIT: this isn't a response to most of the article, but specifically to the
"Moving Forward" section, asking about alternative tools.

Come to the matrix!

[https://matrix.org/](https://matrix.org/)

It's free -- all FOSS, including the entirety of the server -- and yes, all of
it: proof by existence: several of my friends run their own.

It federates. I regularly join channels hosted on several different servers,
and exchange messages without issue.

It's on every platform. I use it on the desktop, my android (cyanogen, without
gapps, none the less!), and my ipad, every day.

It even has voice and video calling built in, using webRTC. This feature has
been a little rough while it was in development, but I used it last week in a
1-on-1 call and had an effortless experience. The audio and video quality was
on par with Google Hangouts.

Crypto is hard, but it's coming. The Matrix developers have huge respect for
the axolotl ratchet design used in Signal. They've worked on making another
implementation (in C, for easier linking in various languages, ostensibly)
here: [https://matrix.org/git/olm/](https://matrix.org/git/olm/)

The deployment of that code to give full End-to-End encryption is a work in
progress, but the beta is roughly functional. It includes everything you'd
expect: communication works by default, but in an encrypted room, messages are
flagged yellow if you haven't explicitly verified the sender's key. There's a
key per device; it doesn't leave the device; and as soon as you verify that
device/key, messages from it are green, and you're E2E secure.

Disclaimer: I have no direct association -- I became a Matrix convert after
trying to write some XMPP client code about a year ago. I'm just really
enthusiastic about recommending it because the tech is solid, the sync is
good, it solves a problem, and the team hasn't stopped either: they been
firing on all cylinders constantly since I started using Matrix.

I love Signal for their dedication to getting encryption right and the
security of their users. But yes, I also share a lot of the concerns listed in
this article. Most of all, I honestly believe federation is an imperative. So,
while acknowledging Signal's history of outstanding security work... Hey,
let's celebrate there's more than one game in town working on alternatives.

~~~
qwertyuiop924
I heard from another thread that Matrix is bad a realtime messaging, and quite
slow at it. Is this true?

~~~
heavenlyhash
Not even remotely.

It's quite _good_ at realtime, and especially _reliable_ realtime. Compared
with protocols like XMPP, Matrix scores way higher on reliability because it
has message IDs and message ordering baked into the protocol, so it can
actually _converge_ on a correct state after network flakes. (I consider this
a pretty big deal because silent message drops were a pretty regular issue for
me in XMPP, and we all know about netsplits in IRC. I've simply _never_ had
silent message loss in Matrix because the protocol is _simply better_.)

~~~
qwertyuiop924
Ah. It was claimed by
[https://news.ycombinator.com/item?id=12880856](https://news.ycombinator.com/item?id=12880856),
but that was an XMPP developer, so there's a bias.

~~~
heavenlyhash
It's true that it's a big hunk of JSON. And I'll readily concede that when
efficiency matters, I'm more partial to binary formats like CBOR. But XMPP is
XML, which... isn't exactly lighter.

There's another HN thread where I've talked more about XMPP vs Matrix here:
[https://news.ycombinator.com/item?id=9772968](https://news.ycombinator.com/item?id=9772968)
\-- long story short, I _tried_ to write an XMPP client, and I got grey hairs,
fast. The story for consistent delivery is pretty much bananas. (And huh,
based on that date, I guess I've been a Matrix convert for almost TWO years
now! Time flies.)

I'm not entirely sure what the comment about battery is about either. If
anyone has a networking technology that can work without turning on the phone
radio, I'm sure we'd all love to hear it...?

Practically speaking, I leave the Matrix Vector app open on my phone
constantly. As of this morning, I have half a charge, and three more days of
charge to go. I don't have any other apps to provide a good comparison here,
but I'll leave this screenshot here for what it's worth:
[https://matrix.org/_matrix/media/v1/download/matrix.org/IgkU...](https://matrix.org/_matrix/media/v1/download/matrix.org/IgkUoQxhTNUvErfkrcKBSfrP)
Looks like my phone has spent about the same order of magnitude of battery on
just plain paging the cell towers as I moved around the city. As other
comments on this thread cover, if you use proprietary Google stuff, you can
wake the phone up slightly more efficiently. But whatever this app is doing
works pretty fine for me.

~~~
SamWhited
XMPP only has to turn the radio on full power mode when it gets a new message
or creates a new connection (the tower sends the LTE radio a paging message
telling it to wake up, then the long-lived TCP connection can receive data).
Matrix has to turn the radio on every single time it wants to check for data,
regardless of whether there is data to receive or not. This is the problem
with HTTP based protocols; you _might_ have a persistent TCP connection, but
it doesn't help you when you have to send a request just to check if there are
new messages.

It's not a case of radio _off_ vs _on_ , it's a case of the radio being able
to stay in RRC_IDLE mode (which I've probably called "off" more than once,
which is where the confusion came from I'm sure, apologies for that) for more
of the time, where as with Matrix it almost always has to remain RRC_CONNECTED
mode.

~~~
Arathorn
I don't believe this is true. The long-polling that Matrix does in the
baseline impl is just a long-lived HTTP request which blocks until the server
has something to send it. Radio-wise this is conceptually the same as an XMPP
TCP connection.

The only difference is that (in the baseline impl) you start a new HTTP
request after receiving each response - which chews some additional data
relative to XMPP. The radio will already be spun up from receiving the
previous data, though, so it shouldn't impact significantly on battery
consumption.

Also, we put a timeout on the long-lived request (typically 30-60s), to aid
recovery in case of the request or connectivity breaking - which could
theoretically increase bandwidth and radio battery consumption, but in
practice almost all Matrix use cases involve receiving events more frequently
than the timeout, so the timeout doesn't actually have much impact on battery.

That said, there is (deliberately) huge scope for improvement with alternative
transports - using strict push rather than long-polling; using transports with
less overhead; using more efficient encodings, etc.

------
cbsmith
There's a fundamental assumption here: that there is a better way. I'm not
saying there isn't, but there's a pretty good existence proof that Signal is
the best combination of security & simplicity we can put together.

I would agree with this statement from the article: "there should be a tool
that is fully free software (as defined by the GNU GPL), that respects users'
freedoms to freely inspect, use, modify the software and distributed modified
copies of the software. Also, this tool should not have dependencies on
corporate infrastructure like Google’s (basically any partner in PRISM), that
allows these parties to control the correct working of the software."

There are such tools. None of them are as easy to use as Signal. So for now, I
recommend Signal. I can't, in good conscience, recommend anything else... and
given the author doesn't speak to what they recommend, I'm curious about what
their recommendation would be.

------
zabuni
"Also, there’s the issue of integrity. Google is still cooperating with the
NSA and other intelligence agencies. PRISM is also still a thing. I’m pretty
sure that Google could serve a specially modified update or version of Signal
to specific targets for surveillance, and they would be none the wiser that
they installed malware on their phones."

Isn't part of the reason that Moxie went with the Google Store is that he gets
to sign the god damned binaries, making it impossible for Google to modify the
app.

~~~
sandervenema
Hi, author here. Yes, my point with that sentence was that the average (non-
technical) user (to which Signal is marketed btw), is not going to check
signatures. Google has root on the phone, the user is using their app store to
install the Signal app that comes up in the store, and basically Google has
full control over this, and the user would be none the wiser.

Of course, us more technical inclined people could then check the signature,
or compare the apk with one built from the official sources, to see the
difference and complain about it.

But between those things is a time frame where this is possible.

~~~
zigzigzag
Does it, actually?

I was under the impression that the Play Store doesn't run as root and the
package manager API (controlled by the phone manufacturer) is what checks
signatures. Can the Play Store override the signature checks on upgrade and if
so, what codepaths is it using?

~~~
sandervenema
Just a quick look, but this is the PackageManager.java file:

[https://android.googlesource.com/platform/frameworks/base/+/...](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/content/pm/PackageManager.java)

for the Android base framework. It has the checkSignatures() abstract
definition and some other stuff that seems to be the API you talk about. Now
this is all abstract, so some other party (maybe phone manufacturer, possibly
others) must implement these methods to conform to the API. Could Google (or
some other party) not just override the abstract implementation?

I find it hard to believe this is something only the phone manufacturer would
have access to, not Google itself, given that Google has created the entire
operating system basically, and is pulling more and more stuff from the AOSP
into their proprietary apps (like Play services).

~~~
zigzigzag
The subclass would have to be in the same process as the package manager (the
system server) so it being abstract doesn't matter much.

Android doesn't rely so much on root vs non-root: it uses SELinux and lots of
capability based security. Root is still there of course but out of the box,
even the parts under remote OEM control don't run as root. If the OEM wants to
change the basic rules of the system they must push a system update and get
the user to agree to it. Of course a firmware update can change anything but
outside of that I'm not convinced Google can just replace software at will.

------
walterbell
Wire ([http://wire.com](http://wire.com)) has worked well on iOS for encrypted
text/files/audio/video. Open-source client, no contact sharing neeeded. No
phone number needed, you can register with email by using a desktop browser at
[http://app.wire.com](http://app.wire.com), then logging into the mobile app.
Group chat for text only. Timed/ephemeral messages for 1:1 text/files. Feature
matrix, [https://wire.com/privacy/](https://wire.com/privacy/). Could use more
documentation (e.g. on retention of encrypted data) but a lot of questions are
answered on Twitter or Github issues.

~~~
tdkl
> Don't know whether it needs GCM on Android.

The .apk on the site uses websocket, no GCM required.

------
haffenloher
From the post:

" _The Google Cloud Messaging service basically handles message handling from
/to the user’s devices to the Signal servers. The GCM service then handles all
the aspects of queueing all messages and delivery from/to users._"

This is not true. Messages are delivered via Signal's own servers only. GCM
messages are empty; their only purpose is to wake up your device. [1]

" _The phone component of Signal is called RedPhone. The server component of
this is unfortunately not open source [...] this is also probably the reason
why secure encrypted phone calls don’t work in e.g. LibreSignal_ "

No. The reason for that is that the signaling for RedPhone calls is currently
still done via GCM and not via Signal's own message transport.

Regarding microg: I've never heard of the need to re-compile kernels for that.
I think most people use it with Xposed (admittedly, a giant hack, but it
works).

[1] [https://whispersystems.org/blog/goodbye-encrypted-
sms/](https://whispersystems.org/blog/goodbye-encrypted-sms/)

~~~
sandervenema
Hmm. You seem to be right. Article corrected there to reflect that Signal is
using empty GCM messages. I must have still had the old situation of
TextSecure in my head when I wrote that. Nice to know re the reason Redphone
doesn't work, thanks for that insight!

~~~
tptacek
_(had suggested the author add an endnote; they did)_

~~~
sandervenema
Yes, I agree that's more transparent. I've added an endnote, and linked to it
from the place where the edit was made.

------
joecool1029
Can't wait for moxie to jump into the commentary. :)

>Lack of federation

Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in
sync with his development. They didn't. Someone will need to volunteer to run
their own server that's kept updated, then buy Moxie a Snickers and hope he
stops being moody.

>Dependency on Google Cloud Messaging

Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for
Android because what else is as robust and doesn't eat battery? Moxie's voiced
support of Websockets if someone implements it correctly and he can merge it
as a fallback option when Play Services are missing. If you can't code and
want it, contribute to the bounty on it:

[https://github.com/LibreSignal/LibreSignal/issues/37](https://github.com/LibreSignal/LibreSignal/issues/37)

[https://github.com/LibreSignal/LibreSignal/issues/43](https://github.com/LibreSignal/LibreSignal/issues/43)

> Your contact list is not private

[https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

TL;DR, it's a tradeoff because nobody has a better idea that works at scale
and is usable. Redphone used to have a good way of blindly doing contact
discovery but it would require too much data for their current userbase.

~~~
secfirstmd
Layoff the personalised attacks on the psychology of someone who has helped
increase the security of hundreds of millions of people for free, on basically
a shoestring. Making pro/against arguments about Signal is fine but Moxie is
genuinely a nice person (as are the rest of the former and current OWS team),
so let's keep the argument civil.

~~~
joecool1029
I actually insulted the Cyanogenmod team and I think it's funny you missed
that.

I don't have an issue with Moxie except that he's been pissy over this and a
few other issues. I don't think anyone is going to argue that he isn't. Why
not check the first link to the Libresignal thread and read his comments on
the topic?

(EDIT: I get the downvotes on this comment, but like Moxie, I too am seriously
annoyed that Cyanogenmod dropped the ball so bad with them. Moxie would need
to get over it if there's a new solution in the future and HE ALREADY VOICED
HIS OPINION THAT FEDERATION IS UNLIKELY. If that's not being pissy, I don't
know what else is. I used to run Libresignal on BB10 and now I can't because
of this policy of being anti-federation and no work moving forward on
websockets fallback. He'll likely say no to approving the fallback on
Replicant/Sailfish/BB10 because he doesn't get version reporting through
analytics and is concerned about disturbances of the signal server.)

------
Canada
Nothing is stopping anyone from running their own servers, changing the
username scheme, and implementing the voice signaling. Moxie doesn't complain
about such usage. But that's more work than simply complaining and telling OWS
what they should do.

As far as usernames go, that would require the signaling key to be remembered
by the user. That doesn't work well in practice. As far as contact sync goes,
has anyone submitted a patch for the android client to add an advanced option
to disable that? On IOS access to the address book is user controlled at
runtime. destinations will be validated by the server at compose time.
Regarding federation, let's see some code. It's ridiculous to demand the small
team that is OWS solve every single problem.

~~~
JupiterMoon
> Regarding federation, let's see some code. It's ridiculous to demand the
> small team that is OWS solve every single problem.

Moxie has explicitly rejected federation. Anyone writing such code is wasting
their time it won't get accepted.

~~~
Canada
Yep. You can run your own federation though. And maybe if it's really awesome
he'll change his mind.

------
nickik
I have started to read about matrix a lot.

\- It now supports e2e encryption.

\- It has a nice web and mobile client, called riot.im

\- I has many other client options

\- You don't need to show any phone numbers.

\- Federated, you can host your own server

------
droopybuns
Animated GIFS were the straw that broke the camels back?

Let's throw the best available solution under the bus.

This post will be my go to example of the myopia of some members of the
security community. We have very few examples of well executed, consumer
friendly privacy soloutions. Signal is the best for all possible scenarios:
Open source, user friendly, buy in from a major Internet service.

I like wickr, but it falls short due to the closed source nature of the
project.

Consumer friendly, usable security needs to be the number one priority for
security advocates. We need to stop burning down houses because they are short
a door or are the wrong color. The foundation is the hard part. Wait till
there is a real alternative that can be used by people who are not c.s. majors
before you argue that people should stop using the best available solution.

I appreciate the authors perspective and I agree with some of their points.
Then they fuck it up by demonstrating purist jackassery. Worth a read as a
useful persuasion antipattern.

------
secfirstmd
I've trained hundreds of human rights defenders and journalists over the last
10 years and I will continue to recommend Signal. For too long the community
has placed perfect security over usability - there are slightly more secure
ways to communicate than Signal but they are far too disruptive to peoples
work flows to actually be implemented.

------
latkin
> this tool should not have dependencies on corporate infrastructure like
> Google’s (basically any partner in PRISM)

Free yourself from the bonds of corporate infrastructure by installing this
tool on your Google Android or Apple iPhone device (Microsoft Windows desktop
version coming soon).

------
qwertyuiop924
There are several projects moving toward this. Matrix is probably the most
well-known project, but its crypto isn't actually operational yet, AFAIK.

Tox works now, but for all their talk of trying to be user-friendly, asking
users to exchange long alphanumeric sequences inherently isn't.

Psyc, maybe?

~~~
SamWhited
Matrix's protocol design is terrible for realtime messaging though (I'm sure
there are other uses for which it's more adept); it's effectively a giant,
inefficient, JSON datastore that syncs data everywhere. It's also pull based
so it consumes battery like crazy. If that's what you need, fine, but for
realtime messaging I'd argue that it's really unacceptable.

~~~
qwertyuiop924
Okay. Tox, anybody?

~~~
SamWhited
I haven't looked into Tox, but I'd be curious to find out the highlights.
Really I've just never understood why people complain about XMPP; yes, it's
XML which is ugly, but it's also the right tool for the job (easy to stream,
very fast SAX-style parsers, event based, etc.), it certainly has its warts, I
won't pretend it's perfect, but for the most part it's been around for 20+
years getting the kinks worked out. If we just keep creating new protocols
because it's not perfect, we'll never get a more or less universally federated
chat protocol like we have for more long form messages (email). I don't know
anyone who would say email was the most wonderful modern thing in the world,
but they still use it because it's good enough and was lucky enough to become
ubiquitous. Similarly, I feel like people should just use XMPP even if they
don't like it for that reason (although I'd still love to find out more about
Tox, what it's strengths and weaknesses are, etc.)

~~~
qwertyuiop924
Tox is a fully distributed ( _not_ federated) p2p system. It supports 2-way
messaging, multi-way chatrooms, voice and video calling (using Opus and VP8,
respectively), file sharing, and desktop streaming, although not all features
are supported by all clients. Although any client can implement any feature
they like, so long as they can do it atop the actual network system, sticking
to the Tox Client Standard is reccomended for maximum compatability. It
implements perfect forward security, and uses libsodium for its crypto. There
are a variety of clients, although most seem to use toxcore, the reference
protocol implementation, under the hood. However, the spec is readily
available, and there are independant implementations.

Tox's goal is essentially to create a user-friendly Skype-like chat
application, with not centralized server, and strong security by default.

The downside is that your user ID on tox looks like this:

    
    
      56A1ADE4B65B86BCD51CC73E2CD4E542179F47959FE3E0E21B4B0ACDADE51855D34D34D37CB5
    

And you have to give it to anybody who wants to connect to you on tox. There
are services like ToxMe which can give you email-style shorthands, but as the
Tox FAQ notes, this can leave you and your contacts vulnerable to an MITM
attack, if the site you use is untrustworthy.

~~~
SamWhited
> Tox is a fully distributed (not federated) p2p system

Ah, see, you lost me there already. I'm sure it's clever and well made and all
the rest of it, but fully distributed systems either almost never work, are
very difficult to get setup and use properly, or end up just not being fully
distributed systems (eg. early Skype and it's "supernodes" or whatever it
called them, aka "servers", or Tor [which I love] and it's directory
authorities which admittedly are elected, but even so are effectively just
"servers", or Bittorrent which has either trackers, aka "servers", or hard-
coded DHT bootstrap nodes, aka also "servers").

Distributed systems sound great in theory, but in the real world I just never
think they're worth the effort, or you have to compromise them and add some
centralized element anyways, at which point you might as well just use a
federated system so that people who don't want to deal with all that can use a
third party server and people who do want their own specially contained
distributed node can just run their own server and client.

~~~
qwertyuiop924
Tox has DHT bootstrap nodes, but they aren't hardcoded.

~~~
SamWhited
Who bootstraps the bootstrap nodes?

~~~
qwertyuiop924
The bootstrap nodes were probably the first ones on the DHT: hence, no
bootstrap needed. If it's a new bootstrap node, it's connected to the old
bootstrap nodes, or some other set of nodes in the DHT, just like any other
node: distributed, not federated.

But once a node is acutually inside the DHT, it should never need to talk to
the bootstrap nodes ever again: that's a pretty major win, in some respects.

~~~
SamWhited
Sorry, that was supposed to be a silly joke, but it also made it horribly
unclear. I meant: How do you find the nodes to bootstrap yourself into the DHT
in the first place? They must be IPs shipped with the client?

~~~
qwertyuiop924
Yes, there are. However, they can be replaced with other servers if the user
wishes.

------
youdontknowtho
If they are only using GCM as a queue (and the messages are themselves
encrypted) I don't understand what the problem is.

They could use anyone for that functionality. Even if the messages are given
to an "adversary" what can they really get from that? Your phone app contacted
the signal servers. That's really it.

~~~
haffenloher
They're not even using it as a queue, they're queueing and delivering the
messages themselves. GCM messages are empty and are only used to wake up your
device.

------
joecool1029
Redphone component.

I don't know why it's closed source. It's been suggested elsewhere in this
thread that it was potentially IP issues they kept it closed for. Is it
possible loose US CALEA law interpretation influences the reasoning? Or a gag?

I honestly don't know why they chose to do that but I wanted to comment in to
see if a lawyer or someone from the project could hint at the reasoning.

~~~
theGimp
[https://github.com/WhisperSystems/Signal-
Android/tree/master...](https://github.com/WhisperSystems/Signal-
Android/tree/master/src/org/thoughtcrime/redphone)

~~~
codethief
This is the _client_ component. The blog post and your parent were referring
to the server component.

------
lisper
I'm working on a completely open secure communications suite based on
TweetNaCl. Proof-of-concept prototype is here:

[https://github.com/Spark-Innovations/SC4](https://github.com/Spark-
Innovations/SC4)

Working on a better UI at the moment. Could really use help, especially beta
testers.

------
rstuart4133
I know the redphone is library is just a binary blob in the github repository:

    
    
        https://github.com/WhisperSystems/Signal-Android/tree/master/libs/armeabi
    

But I always thought that .so was just a compiled version of this C++ source,
which in the same github repository:

    
    
        https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone
    

I haven't compiled it myself so I can't be 100% sure, but the C++ entry points
matches the API the Java code is using. I presume it's written in C++ for
speed. There isn't much to the C++ bits. It just pumps data through an
encrypted RTP connection - CPU intensive but not particularly complex.

The server code is up there too - in fact it's all up there. AFAICT, Signal is
completely open source.

------
gyey
I haven't actually worked with GCM so please forgive me if this doesn't make
any sense. I suggest that, instead of routing all messages through GCM, what
if Signal could send a "wake up" message via GCM, and then let the app pull
the encrypted messages directly out of Signal's servers? A wake up message
would only be sent by the server if the message could not be received by the
client via normal means (implying that the device is asleep).

An optional user preference could allow some dummy wake up messages to be sent
at random moments during the day, to support plausible deniability, at the
cost of slightly worse battery life performance. This would all happen
silently and the user would only notice a message notification when the app
successfully fetches a new incoming message.

~~~
haffenloher
> I suggest that, instead of routing all messages through GCM, what if Signal
> could send a "wake up" message via GCM, and then let the app pull the
> encrypted messages directly out of Signal's servers?

Yep, that's exactly how Signal has been doing it for >1.5 years now.

~~~
gyey
ahh. I just thought otherwise from some of the other comments here. Makes
sense. Thank you.

------
em3rgent0rdr
I didn't have to recompile my kernel to use microg...instead I used FakeGApps
with Xposed framework. instructions:
[https://github.com/thermatk/FakeGApps](https://github.com/thermatk/FakeGApps)

------
codemac
Signal is to get people from SMS and iMessage -> Signal. This means that cross
platform communication becomes secure in transit.

Once Signal and others have really wiped out all the insecure messaging people
are doing, then we can start with the identity problem with phone numbers.
GCM, Contacts, etc are all related to this "phone number as identity" problem.

RCS is an unfortunate grab in this space, and we need to move fast before RCS
is the default, and we're back to insecure messaging.

Email addresses are the best form of "federated identification" but are wildly
insecure for communication. Here's to hoping we can get some better ones.

------
RustyRussell
For me I won't recommend it because of the horrible lack of options when you
replace your phone (let alone lose it). No encrypted migrate. No backup
options. Unencrypted loses content (images).

Plus there's no way to search old messages.

~~~
majewsky
I guess these are all features. For example, how are you going to do a backup
that restores when you lose the phone (and thus the private key)? In practice,
you would encrypt the backup with a passphrase, and the user would choose
"123".

Signal aims to be the most usable secure messenger, not the most usable
messenger that also happens to be secure.

------
lonelyw0lf
The truth which a lot of Moxie fans don't want to admit is he thinks there is
nobody better to be entrusted with this project. I don't think this was ever
meant to be a community project -- he just opened some parts so he could
pretend it is. Also he is a limelight hogging security diva who always wants
to be in the news and have people talk about him. If he allowed others to
contribute and be recognised, he worries they might overshadow him.

------
argos-rho
The author offers no better alternative so I think that means the article
speaks for itself: there's not much to do but whine. These are problems, sure,
but they're minor when you consider that Signal is the most secure and user-
friendly messenger we have on the market right now. If something takes its
place, then great. Otherwise, we just will continue to use what is secure and
actually works.

------
raverbashing
\- Lack of federation

Use a federated secure protocol. Oh wait, there are none. Because if a problem
appears you just can't fix it without breaking all federated clients. And then
they will whine.

\- Dependency on Google Cloud Messaging

Fair enough

\- Your contact list is not private

Fair enough

\- The RedPhone server is not open-source

While it would be nice that it was Open sourced I can understand them not
releasing it (might be for IP issues)

tl,dr: "Signal does not work the way I wanted"

~~~
qwertyuiop924
Umm... Tox?

~~~
exo762
Tox on mobile? Have you actually tried to use it? It drains your battery like
crazy.

~~~
qwertyuiop924
He didn't ask about that. He asked about a federated/distributed protocol that
actually worked. Tox is one.

------
1024core
> Another issue, and a plus for using usernames, is that you may want to use
> Signal with people you don’t necessarily want to give your phone number to.

So, how do you know that the Edward.Snowden@signal you're communicating with
is the same Ed Snowden that we all know about, and not some TLA stooge?

~~~
resonanttoe
You're missing the point. Neither Phone number of Email address/username solve
the problem you're proposing. But an email address/username is a lot more
transient than a phone number.

I can change emails/usernames very easily and with little effort, and while
burner numbers and applications that help that exist, changing phone numbers
is not as easy and thus a significant percentage of users are unlikely to do
it regularly. So you have a pseudo real ID that to the end user FEELS like it
isn't you, but is a very strong (no pun intended) signal that it is to anyone
looking in.

The phone number grants no you special verification of identity over an email
address that doesn't involve an external verification mechanism (i.e, talking
to the identity in person.)

------
ttam
funny enough, I was going to try out Signal today but stopped right after
seeing the permissions they request:
[https://pbs.twimg.com/media/CwhFsLzXcAIDcMH.jpg:large](https://pbs.twimg.com/media/CwhFsLzXcAIDcMH.jpg:large)

~~~
codethief
Well, everything is there for a good reason. (Though it escapes me right now
why it needs permission to access the calendar.) How are you going to call
someone over Signal if Signal can't use the microphone? If in doubt you can
always check the source code – it's open source for exactly that reason.

------
HashThis
How does Signal compare to Telegram? Would you recommend Telegram as better or
worse then Signal.

~~~
encryptawaa
On Signal, every message uses end-to-end encryption. Signal's servers can't
see the messages you are sending, only you and the recipient can read them.
Signal's encryption protocol is carefully scrutinized and follows best-
practices.

Telegram sends messages in plain-text by default. Telegram servers have access
to all plain-text messages that you send.

Telegram's private chats use end-to-end encryption. But they use an encryption
protocol that they invented themselves that doesn't follow best-practices.
Encryption experts have been critical of Telegram's encryption protocol since
it was released. So your private messages might not be so private, either.

If you are doing something sensitive and want to stay out of prison, use
Signal.

~~~
majewsky
Actually, _always_ use Signal unless you have contacts on Telegram that refuse
to migrate. Consider all communication via Telegram to be on public record.

~~~
jhasse
> Consider all communication via Telegram to be on public record.

Just because the protocol has flaws, doesn't mean everyone can exploit them.

On the other hand it's possible for Google to read every communication because
they have root on your phone. So using Telegram [1] with a custom ROM without
Google services (e. g. [2]) will make it harder for Google at least. Not
easily possible with Signal.

[1]
[https://f-droid.org/repository/browse/?fdfilter=telegram&fdi...](https://f-droid.org/repository/browse/?fdfilter=telegram&fdid=org.telegram.messenger)
[2] [https://copperhead.co/android/](https://copperhead.co/android/)

------
nopcode
Why is the author asking for GPL?

Wouldn't a ISC/BSD-like license be better for the federation aspect?

------
richardwhiuk
If you aren't going to recommend anything else then sit down and shut up
frankly. The world is made of compromises and saying I don't like your choices
is pointless if it's effectively impossible to choose differently.

------
wtbob
I am also very unhappy with the direction Signal has gone, but there's
currently no alternative. I'd be interested in contributing to work attempting
to replicate it, though.

~~~
zanny
I have some friends in an encrypted riot room right now. The olm could use a
real good audit, but otherwise it is working right now. Federation is working,
bridges are working, voice and video are working, it has Android and iOS
clients. The only problem is the encryption doesn't apply to the voice / video
or shared files yet, but they have made huge progress this last year from
basically nothing so far.

~~~
heavenlyhash
+1. I'm super happy with the Matrix / Riot ("riot" is the client) crypto work
over the last year.

It's such a relief to have a modern chat system that's FOSS, federates, and
offers a liiiiitle more advanced UX than irc...

------
angry_octet
If wishes were fishes we'd all live by the sea.

------
empath75
Any service that owns valuable user data is going to get compromised
eventually, whether they do it themselves, or are the victims of an attack. I
feel like the only way to not get swept up in the surveillance state is to
never put your data on one of these services at all.

------
fiatjaf
The Signal app is stupid. It doesn't work intuitively as WhatsApp. It's
incomprehensible that you need a phone number, it's incomprehensible that you
can't compile it yourself.

------
kingad
What are your views about VoIP with ZRTP?

~~~
mtmail
That's unrelated (off-topic) to Signal and what the blog post discusses, isn't
it?

~~~
fragmede
Though it wasn't explicitly mentioned in the blog post, Signal _does_ support
encrypted voice calls, so GP post isn't entirely off topic.

------
piotrjurkiewicz
Add a lack of real desktop to this.

~~~
piotrjurkiewicz
*real desktop client

------
bitmapbrother
>I’m pretty sure that Google could serve a specially modified update or
version of Signal to specific targets for surveillance, and they would be none
the wiser that they installed malware on their phones.

I'm not sure he understands how app signing works and why it would be
impossible for Google to forge a developer's signature. He also seems to have
a problem with GCM and Google in general. Perhaps he should look into writing
his own secure chat application.

~~~
throwaway101416
Why would they have to forge it? They can simply install a version that isn't
signed on your system via an update.

Then later replace it with a signed version once they have the data they
wanted. You would never know what happened.

------
sctblol
Hmm... he mentions the Giphy thing at the beginning of the article, then never
again.

The Giphy mention seemed really dangerous to me. Now I don't use Signal but I
imagine it's 1) optional and 2) requests are proxified/anonimised through an
intermediary (the Signal servers in this case). And why is this dangerous?
Because this "don't build cool stuff on this serious app" is what makes people
not use the app. It's creating boring, dull apps what stops them from becoming
mainstream successes. If we are trying to make the public using secure apps
because we believe in privacy, we have to make them appealing.

This is similar to the case of how nobody uses PGP because how horribly bad it
is, UX-wise.

That said the rest of points he brings up are good. I just didn't like the
Giphy mention, especially taking into account he didn't say anything else
about it, he just brought it up.

~~~
sandervenema
Hi there! The Giphy thing is what set me off writing the blog post in the
first place. Maybe I should've expanded a bit more on that in the article. As
far as I can tell, the idea is that requests to the Giphy API gets proxied
through Signal.

I don't see anything in moxie's blog post about whether this is optional. If
it isn't and it's sending everything you type to the Giphy API then we have a
whole new problem.

In the blogpost by moxie, there's the example of typing "Im excited", which
then gets sent in multiple API requests to giphy (basically one of 'I', one of
'Im', one for 'Im+' etc.). Now, if this is an action you don't do _explicitly_
(like pressing a button or something, to search for gifs), then it would
basically send everything you type in order to continually search for gifs and
then offer suggestions? It's not clear from the blogpost. I hope at least that
this is _not_ what moxie had in mind.

~~~
giancarlostoro
Giphy only occurs when you click on a button to add an attachment, and you
have to click on Giphy, THEN you search for GIFs.

------
joesmo
"Otherwise, we’ll be in danger of ending up in an neo-90s Internet, with
walled gardens and pay walls all over the place. You already see this trend
happening in journalism."

The internet will never be less walled, more free, and more federated than it
was in the 90's. With such a poor understanding of the internet and its
history, even if he did make a compelling argument (he doesn't), it'd be hard
to take seriously.

~~~
qwertyuiop924
You're forgetting about AOL and Compuserve. The Internet itself was federated.
Networking really wasn't.

~~~
joesmo
I forgot them on purpose because he's talking about the Internet, not
networking, not BBSs (which AOL and Compuserve were just big versions of). AOL
and Compuserve eventually made themselves just another part of the Internet,
but before that, they were really irrelevant in relation to the Internet's
federation. In fact, other than AOL being an ISP and a gateway to the Internet
for many, the actual AOL service was completely irrelevant once Internet
connections came along.

------
draw_down
> _The big question now... is what post-Signal tool we want to use. I don’t
> know the answer to that question yet_

Oh.

