This isn't entirely true. A detailed explanation is available in the Open WhisperSystems Support Center [1] and several solutions are in the works. Google's GCM push messaging framework is used only for message delivery; the TextSecure server itself is open source [2].

[1] http://support.whispersystems.org/customer/portal/articles/1... [2] https://github.com/WhisperSystems/TextSecure-Server

It's true currently. At the support page you link first it is promised that it will be eventually changed but now: "Outside of Google's GCM, the fact is that there are no alternative push messaging frameworks for Android that can scale to the millions of users that TextSecure has. GCM requires Google Play."

Note, the page confirms: Google Play still has to be installed to use TextSecure on Android. That is the current state. Google has practically the root access to the every Android device which runs TextSecure.

Full disclosure: I wrote that Support Center article. The comment I was replying to made it sound as though TextSecure's infrastructure is almost entirely Google-based. It is not, and that's what I meant when I said "This isn't entirely true." The server is open source and it already includes preliminary support for WebSockets and Apple's APN push messaging network. Google's GCM is merely one component, and alternatives are being worked on.

Apple also has root access to all iOS devices via their over-the-air update framework. Opaque basebands and graphics chips with closed source drivers are difficult to trust too. None of these scenarios mean that software which offers serious improvements over the status quo should be casually dismissed. TextSecure can (and does) provide significant protection from mass surveillance and targeted surveillance. Security nihilism is corrosive.

So it's still true that currently the sever side uses only Google servers. It's nice to hear that there's work on the alternatives.

What you call "nihilism" is simply the observation of the current state. At the moment Google has root access and all the metadata of all TextSecure users, and currently the user can't configure TextSecure to use some other servers even if he'd prefer to do so. Still I'm glad that I've seen that some server-side code is now open source.

The server side is currently relaying messages for the in-progress iOS and Chromium clients. That's functionality that exists today, even though the clients are still under development. The TextSecure server is an elegant and important part of TextSecure's infrastructure. I stand by my assertion that it's an oversimplification to say that TextSecure == Google's Servers.

Google does not have access to any metadata, other than the fact that you are a TextSecure user who has received a Push notification. GCM payloads are fully encrypted. Google cannot tell who a message was from, they cannot see which numbers were involved (users are free to register with a number that is different than the one assigned to the cell phone that is running TextSecure), they cannot tell whether or not it was part of a group conversation, and they cannot see its contents.

Yeah. The more substantial downside is that Google effectively has remote root access to every device which holds decryption keys for that text. That's not exactly ideal.

I would be interested in your thoughts on alternative platforms / firmware /ecosystems which get around this?

Perhaps using Paranoid Android (if supported on your phone) would be a start.

I would rather pay a nominal fee to support their infrastructure than have to rely on Google Play Services for a supposedly "secure" messaging service.

I see you point but it should not weaken the security because encryption happens at the client, Google "only" gets metadata which at least authorities will get anyway.

Besides, TextSecure is free software so it might possible to run your own server at least in the future.

Google gets the metadata? That's news to me. I thought the metadata was encrypted by the TextSecure server?

Every network that carries your communication gets the metadata.

In this case, it seems like that metadata would 'just' be the time you sent and received messages from the server. Depending on how Google's push protocol works.

So for the average person that would be fine, but if you were seriously annoying a government that was in bed with your phone company, they could probably figure out who was a part of your cell by the timing of your sent and received messages.

I don't know, but I would have guessed that Google needs to know when it should deliver a message and where it should go, no? That is metadata in my definition.

GCM payloads are fully encrypted. Google would be able to tell that you are a TextSecure user who is receiving a message, but they cannot tell who the message is coming from nor can they look at its contents (obviously).

But crucially, this will still be vulnerable to timing attacks, if I'm not mistaken.

What's the specific timing attack you're considering here?

There may not be the traditional byte at a time comparison type timing attack, but maybe this is still vulnerable to timing correlation attacks in the same sense that tor is. That is, Google or someone monitoring Google's network can look at all the messages and see who is talking to whom by matching up timing and encrypted message bodies.

I'm guessing: I send a message, you receive a message -> possible to infer (with some confidence) that I messaged you?

(I don't know if that would be feasible, but I suppose that's what avn2109 meant).

[ie: not a timing attack, but traffic analysis]

Good point. I did indeed mean traffic analysis, not "timing attack."