Most medical and fitness apps in Google Play have tracking capabilities enabled and their data collection practices aren’t transparent

As many as 88 percent of almost 21,000 mobile health (mHealth) applications that are accessible on the Google Play Store from Australia include code that can access and even share users’ personal data with third parties, an analysis by the Optus Macquarie University Cyber Security Hub in Sydney has found.

The paper – dubbed Mobile health and privacy: cross sectional study and published by the British Medical Journal – looked at 8,000 apps classified as ‘medical’ and 13,000 apps falling into the ‘health and fitness’ bracket. These are almost all mHealth apps that are accessible in the Google Play Store from Australia. Overall, close to 100,000 apps across both Google Play and Apple Store belong to the two categories.

As part of their research, the scholars conducted an in-depth analysis of almost 16,000 free mHealth apps found in Google’s app marketplace and compared their privacy practices against a baseline sample of close to 8,500 non-mHealth apps.

What did the research find?

“The main types of data collected by mHealth apps include contact information, user location, and several device identifiers. Part of these identifiers (specifically, international mobile equipment identity (IMEI), a unique identifier used for fingerprinting mobile phones; media access control (MAC), a unique identifier of the network interface in the user’s device; and international mobile subscriber identity (IMSI), a unique number that uniquely identifies every user of a cellular network) are unique and persistent (ie, they are immutable and cannot be changed or replaced) and can be used by third parties to track users across networks and applications,” reads the study.

Two in three apps collected MAC identifiers and cookies, a third collected the users’ email addresses and about a quarter of apps could surmise the user’s current location based on the cell tower they were connected to.

However, compared to other types of apps, mHealth apps collected and transmitted less user data and demonstrated a lower penetration of third-party services. The transmission of data was only recorded in about 4% of the tested mHealth apps, with the most common types of data transmitted comprising users’ names and locations.

While the study concluded that how mHealth apps retrieve and share user data could be considered routine, their disclosure about these practices was anything but transparent. Almost a quarter of user data transmissions, especially data concerning passwords and location data, were observed taking place over an insecure unencrypted HTTP connection. Almost a third of the mHealth apps didn’t offer any kind of privacy policy detailing how data is being handled.

Meanwhile, another quarter of the analyzed apps handled data in a way that clearly violated their privacy policies. This could spell trouble for companies that would be found in breach of privacy regulations such as the European Union’s General Data Protection Regulation (GDPR), which requires that users be clearly informed about how their data is being handled.

“Mobile apps are fast becoming sources of information and decision support tools for both clinicians and patients. Such privacy risks should be articulated to patients and could be made part of app usage consent. We believe the trade-off between the benefits and risks of mHealth apps should be considered for any technical and policy discussion surrounding the services provided by such apps,” the paper concludes.

It’s no news to you that in order to do their job, mobile apps require access to some of your data or your phone’s features, typically contacts, location, microphone or camera. In many cases, however, the apps vacuum up inordinate amounts of personal information and ask for permissions that they don’t really need for one function or another. ESET Chief Security Evangelist Tony Anscombe recently looked at why you should be wary of what kinds of permissions you grant to mobile apps and when the requests are excessive.