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...

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/

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.