Android Calling Home - Part 2

In a previous post I have started looking at with whom and Android based device communicates in the background after it has been switched on. Unsurprisingly, it starts talking with a couple of Google services as detailed in part 1. Naturally, I was wondering if and how that can be reduced again using my private Wi-Fi access point trace setup.

Google Talk

Of particular interest in this regards was first of all Google Talk. In the default configuration, my Android phone automatically registers me to Google Talk after I power on the mobile phone and lists me as available. Further, as part of the default configuration, it updates my Google Talk status as "away" whenever the screen saver activates and again back to "available" every time the screen saver is disabled. In other words, an interaction with Google whenever I use the phone so Google could potentially use the data to track when and how often I use my phone. This behavior can be switched off by starting Google Talk and disabling it in the settings. It's also possible to disable the "auto sign-in on startup of the device" and I did that as well because I don't use Google talk at all. Despite this, my device still starts talking to Google Talk when I power it on. Not sure why that is, the communication is encrypted, so it's not possible to tell. But the question remains, why does it contact Google Talk if I don't want an auto log-on?

Android.Clients.Google.Com

Another interaction that can be reduced is the initial interaction with http://android.clients.google.com when the device starts. By changing the password of the account that is used for the Android market, calendar synch, address book synch, Google Talk, etc., the initial interaction will fail and the device remains quite silent afterward. Even Google Talk remains silent and doesn't attempt to establish a connection to the server. Changing the password of the Google account is best done on the PC by logging in there and then going to the settings page.

Using a different Browser

And another thing that can be done to reduce interaction with the mother ship is to use a web browser other than the built-in one. There are several options such as Opera Mobile and Opera Mini. Opera Mini is a proxy based solution so in theory there could be no correlation between the device and the IP address that anyone could track. Unfortunately, that is not quite the case as the Opera Proxy Server includes the original IP address the request was sent from in the HTTP header in an extension. Not so good for privacy unfortunately. But better than nothing.

Summary

Please don't get me wrong, I have come to very much appreciate Android, it's become a great and flexible mobile OS and its capabilities are stunning. It's open source, it's easy to find the code and I'll rant about that in another post but it's a bit too chatty for my taste with Google. Perhaps if I knew what was going on inside those encrypted connections (they have to be for security reasons obviously) I would feel a bit better but I don't have any insight into that.

So if you apply all the things I've written in this post and the previous one you can quite narrow down the interaction but you can't stop it completely this way. If you want to use the Android market, you have to input account details after which the device starts to become chatty. Perhaps the Amazon market and GetJar are replacements that are worth looking at from a privacy point of view? Also, turning off location services is not such a good idea if you want to use Google Maps. Without the option to report the location of Wi-Fi access points occasionally, the functionality is also disabled in Google Maps and usability is greatly diminished as only GPS is used at this point and acquiring a first location fix takes a bit of time. You can of course switch background location reporting off and on as you need it but that's cumbersome. Yes, an ease of usability vs. privacy tradeoff...

Comments

[Joonas Kuorilehto]

I'm guessing you could add your own SSL certificate in the trusted certificate chain and do some SSL MITM to sniff the traffic. Shouldn't be too hard, but never tried it.

If you want to decode what's going on and not only have to trust the source (since vendors could modify it without telling you), you might want to give it a try. There are ready-made-tools to implement SSL MITM. I'm guessing Android uses SSL/TLS pretty much exclusively and not other encrypted protocols.

[Christopher]

The Google Talk connection is an always-on XMPP connection used for Google's push message service.

This includes pushing "install" messages to your device when you choose to install an app from the Android Market, whether on your phone or from the website.

Here's an article with links to earlier articles which go into some details:
http://jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/