This article is more than 1 year old
Android, iOS beam telemetry to Google, Apple even when you tell them not to – study
Search giant insists it's necessary, iTitan didn't have anything to say
Android and iOS phones transmit telemetry back to Google and Apple, even when users have chosen not to send analytics data.
In a recent released research paper, titled "Mobile Handset Privacy: Measuring The Data iOS and Android Send to Apple And Google" [PDF], Douglas Leith, chairman of computer systems in the school of computer science and statistics at Trinity College Dublin, Ireland, documents how iPhones and Android devices phone home regardless of the wishes of their owners.
According to Leith, Android and iOS handsets share data about their salient characteristics with their makers every 4.5 minutes on average.
"The phone IMEI, hardware serial number, SIM serial number and IMSI, handset phone number etc are shared with Apple and Google," the paper says. "Both iOS and Google Android transmit telemetry, despite the user explicitly opting out of this."
Both iOS and Google Android transmit telemetry, despite the user explicitly opting out of this
These transmissions occur even when the iOS Analytics & Improvements option is turned off and the Android Usage & Diagnostics option is turned off.
Such data may be considered personal information under privacy rules, depending upon the applicable laws and whether they can be associated with an individual. It can also have legitimate uses.
Of the two mobile operating systems, Android is claimed to be the more chatty: According to Leith, "Google collects a notably larger volume of handset data than Apple."
Within 10 minutes of starting up, a Google Pixel handset sent about 1MB of data to Google, compared to 42KB of data sent to Apple in a similar startup scenario. And when the handsets sit idle, the Pixel will send about 1MB every 12 hours, about 20x more than the 52KB sent over the same period by an idle iPhone.
Extrapolated across the estimated US customer base of 129m Android users and 113m iPhone users, that works out to Apple collecting 5.8GB of data every 12 hours and Google collecting 1.3TB in America alone, the team estimates.
Google however contends Leith's figures are off by an order of magnitude.
Leith's tests excluded data related to services selected by device users, like those related to search, cloud storage, maps, and the like. Instead, they focused on the transmission of data shared when there's no logged in user, including IMEI number, hardware serial number, SIM serial number, phone number, device ids (UDID, Ad ID, RDID, etc), location, telemetry, cookies, local IP address, device Wi-Fi MAC address, and nearby Wi-Fi MAC addresses.
This last category is noteworthy because it has privacy implications for other people on the same network. As the paper explains, iOS shares additional data: the handset Bluetooth UniqueChipID, the Secure Element ID (used for Apple Pay), and the Wi-Fi MAC addresses of nearby devices, specifically other devices using the same network gateway.
New lawsuit: Why do Android phones mysteriously exchange 260MB a month with Google via cellular data when they're not even in use?READ MORE
"When the handset location setting is enabled, these MAC addresses are also tagged with the GPS location," the paper says. "Note that it takes only one device to tag the home gateway MAC address with its GPS location and thereafter the location of all other devices reporting that MAC address to Apple is revealed."
Collecting such data, Leith observes, doesn't necessarily constitute a privacy violation, but may when linked to a specific individual.
Linkage of this sort occurs when a user logs in to use Google Play or the iOS App Store and associates the device data with personal details used for authentication and payment, the paper says. It also occurs whenever a handset connects with a backend server and reveals its IP address, which can be used by geoIP services to infer user location.
"Many studies have shown that location data linked over time can be used to de-anonymize," Leith observes in his paper.
Google, however, disputes the methodology Leith employed to make his measurements.
"We identified flaws in the researcher's methodology for measuring data volume and disagree with the paper’s claims that an Android device shares 20 times more data than an iPhone," a company spokesperson said in an email to The Register on Wednesday. "According to our research, these findings are off by an order of magnitude, and we shared our methodology concerns with the researcher before publication."
These findings are off by an order of magnitude, and we shared our methodology concerns with the researcher before publication
Google points out that Android supports many more handset models than iOS, making data about devices more salient from a network and operations perspective. Collecting data on CPU loads and apps that remain active on screen, for example, makes it possible to optimize power consumption.
Google's position is that Leith's research basically just outlines how smartphones work.
"Modern cars regularly send basic data about vehicle components, their safety status and service schedules to car manufacturers, and mobile phones work in very similar ways," the company's spokesperson said. "This report details those communications, which help ensure that iOS or Android software is up to date, services are working as intended, and that the phone is secure and running efficiently."
Google also has a plausible fine-print justification: Leith notes that Google's analytics options menu includes the text, "Turning off this feature doesn’t affect your device’s ability to send the information needed for essential services such as system updates and security." However, Leith argues that this "essential" data is extensive and beyond reasonable user expectations.
As for Apple, you might think a company that proclaims "What happens on your iPhone stays on your iPhone" on billboards, and "Your data. Your choice," on its website would want to explain its permission-defying telemetry. Yet the iPhone maker did not respond to a request for comment. ®