If you are a frequent reader of this blog you are probably aware that I prefer to keep my personal data close to myself. I don't want my personal address book, calendar, etc. etc. with Google or anyone else in the cloud, I don't want anyone collecting location information, anonymously or not without my consent and I don't want my devices to frequently call the mother ship. In this day and age, that's quite a challenge with iOS and Android sending information back into the cloud if the settings are left unchanged. So I was wondering how this data collection works in practice today and how much can be prevented from going out.
To have a closer look at what's going on I set-up a test environment with my Android 2.2 based phone connected to the Internet via Wi-Fi. The Wi-Fi access point was not directly connected to the Internet, however, but instead to the Ethernet port of a notebook that had Internet connection sharing enabled via its own Wi-Fi interface and a second Wi-Fi access point. This way, Wireshark can be used to trace the communication between the mobile device and the rest of the world. To see how Android interacts with Google and the rest of the world and how this can be scaled down I tested three scenarios:
- A device fully configured with a Google account, but calendar and address book synchronization disabled. Most people won't even deactivate this synchronization but I figured that's where most people who prefer to keep their data to themselves would start.
- As above but the Google account inaccessible due to a change of the password.
- After a factory reset without a Google account configured.
Lets take a look at the first scenario:
When the device is switched on, the first thing it does is to connect to synchronize the clock with an NTP time server (north-america.pool.ntp.org). Next, it retrieves GPS ephemeris information (xtra1.gpsonextra.net). This is interesting since gpsonextra.net is a domain registed by Qualcomm (and not Google), the maker of the radio chipset of the device.
After that, the device registers with Google (android.clients.google.com). For the interchange of most information, SSL is used so it's not possible to see what kind of data is interchanged inside the encrypted channel.
If registration with Google was successful the device then registers with Google Talk (mtalk.google.com) as Google Talk starts automatically in the background. This even happens when I configure Google Talk not to log me in automatically. I should add that I never registered to use Google Talk so I guess that comes as part of the Android/Google account.
And finally, the device starts talking to another time synchronization service (time-nw.nist.gov). Since this doesn't happen when I set the date and time to be configured manually, this interaction is probably there to check and correct the Android date and time. Again, this is not a Google service, NIST is the National (US) Institute for Standards and Technology. From that I infer that the NTP interaction above might be for the Qualcomm GPS calibration and not for Android itself.
All these interactions take place in the first few seconds after Internet connectivity has been established. After that, the device remains quiet until an app is started that interacts with a server on the network.
I wasn't able to trace an interaction with the Google location server that is reported to scan for WiFi SSIDs and Cell-IDs on a regular basis if this is not disabled in the configuration. This is most likely because my setup was stationary so the device was not able to collect information.
Put together, there is quite some interaction going on with the default settings. As mentioned above, many things can be disabled in the configuration. In a follow-up post or two I'll have a look at what can be prevented from going out and how that limits the use of the device.