Xiangyu Liu

Zhe Zhou

Wenrui Diao

Zhou Li

Kehuan Zhang

An Empirical Study on Android for Saving Non-shared Data on Public Storage

With millions of apps provided from official and third-party markets, Android has become one of the most active mobile platforms in recent years. These apps facilitate people's lives in a broad spectrum of ways but at the same time touch numerous users' information, raising huge privacy concerns. To prevent leaks of sensitive information, especially from legitimate apps to malicious ones, developers are encouraged to store users' sensitive data into private folders which are isolated and securely protected. But for non-sensitive data, there is no specific guideline on how to manage them, and in many cases, they are simply stored on public storage which lacks fine-grained access control and is almost open to all apps. Such storage model appears to be capable of preventing privacy leaks, as long as the sensitive data are correctly identified and kept in private folders by app developers. Unfortunately, this is not true in reality. In this paper, we carry out a thorough study over a number of Android apps to examine how the sensitive data are handled, and the results turn out to be pretty alarming: most of the apps we surveyed fail to handle the data correctly, including extremely popular apps. Among these problematic apps, some directly store the sensitive data into public storage, while others leave non-sensitive data on public storage which could give out users' private information when being combined with data from other sources. An adversary can exploit these leaks to infer users' location, friends and other information without requiring any critical permission. We refer to both types of data as "non-shared" data, and argue that Android's storage model should be refined to protect the non-shared data if they are saved to public storage. In the end, we propose several approaches to mitigate such privacy leaks.

3 Although an app needs the corresponding permissions (like READ EXTERNAL STORAGE or WRITE EXTERNAL STORAGE, READ and WRITE for short) to access public storage, these permissions are very common and are usually granted by users without any hesitation since they are requested by most apps.

Introduction

The last decade has seen the immense evolution of smartphone technologies. Today's smartphones carry much more functionalities than plain phones, including email processing, social networking, online shopping, etc. These emerging functionalities are largely supported by mobile applications (apps). As reported by [START_REF]Android apps on google play[END_REF], the number of Android apps on Google Play is hitting 1.55 million.

Most of the apps need to access some kind of users' data, like emails, contacts, photos, service accounts, etc. Among them, some data are to be shared with other apps by All vulnerabilities described in this paper have been reported to corresponding companies. We have got the IRB approval before all experiments related to human subjects. nature, like photos from camera apps, while others are not to be shared (which is called "app-private data" in this paper), like temporary files, user account information, etc. To protect these app-private data, Android has provided multiple security mechanisms. A private folder is assigned in internal storage that can only be accessed by the owner app.

App developers tend to further divide app-private data into sensitive and non-sensitive ones (the reasons are discussed in Section 7). The sensitive data, like user authentication information, are saved to internal storage, while the data deemed as non-sensitive are saved to public storage (including external SD card and shared partition in built-in Flash memory) which lacks fine-grained access control and is open to almost all other apps 3 . At first glance, it seems reasonable and secure to differentiate and save those "nonsensitive" data to public storage. However, this is a dangerous practice for two reasons. First, app developers prone to make mistakes on identifying sensitive data, especially when the data are massive and complicated. Second, some data could be turned into sensitive when combined with data from other apps or publicly available information, even though they are non-sensitive when being examined individually.

In this paper, we investigated a large number of apps, and the results show that many app developers indeed have failed to make right decisions and app-private data that are originally thought as "non-sensitive" could actually leak lots of user privacy (more details are described in Section 4). We also demonstrate one concrete attack example on inferring user's location by exploiting those "non-sensitive" information in Section 5, which further proves the seriousness of the problem.

We argue that the problem identified in this paper is distinct from previous works. It reveals the gap between the assumptions of Android security design (i.e., the security relies on the knowledge of app developers and permissions) and the limitations in real-world (i.e., apps always need to be compatible with all Android versions and all devices and app developers are not security experts). Our study suggests a vast number of Android apps fall into the trap due to this gap, which is much more serious than people's thought before and needs to be addressed urgently. However, such problem neither originates from system vulnerability nor is introduced when user is fooled, and the existing protection mechanisms are therefore ineffective. To bridge the gap, we believe that app developers should scrutinize their code and avoid saving any non-shared data to public storage, no matter if they are identified as sensitive or not. In other words, "public storage" can only be used to save data to be publicly shared with other apps. Another less painful approach requires the update of Android infrastructure by bringing fine-grained access control to current public storage model, which essentially converts shared public storage to non-shared storage.

Our Contributions. We summarize our contributions as follows:

-We revisit Android's public storage model, including its evolution and access control mechanism. -Our study is the first to examine the privacy leakage on public storage by investigating real-world apps. Some discovered issues are critical and should be fixed as soon as possible. We manually checked the most popular Android apps on whether they store the data correctly, and the results show that most of them (with billions of installations in total) leave user's private information on public storage. Our largescale automated analysis further indicates that such a problem exists in a large number of apps. We also show it is possible to harvest sensitive information from very popular apps through a showcase.

-We suggest several approaches to protect app-private data on public storage.

Adversary Model

The adversary studied in this paper is interested in stealing or inferring device owners' sensitive information by exploiting the app-private data located at public storage. In order to acquire app-private data, it is assumed that a malicious app with the ability to read data on public storage (by requiring the READ or WRITE permission) and access the Internet (by requiring INTERNET permission) has been successfully installed on an Android device. The app will read certain app-private folders selectively on public storage, extract data that can be used for privacy attacks, and then upload them to a malicious server where the data are analyzed to infer victim's sensitive information.

The above assumptions are easy to be satisfied. First, the app requires only two very common permissions. A statistical analysis on 34369 apps (crawled by us) shows that about 94% of apps request INTERNET permission, and about 85% of apps request the permission to access public storage, ranking No.1 and No.3 respectively. This malicious app should hardly raise alarm to the device owners during installation. Second, it only uploads data when Wi-Fi is available and therefore it is hard to be detected by looking into data usage statistics. Finally, the app does not exhibit obvious malicious behaviors, like sending out message to premium number or manipulating the device like bot-client, and could easily stay under the radar of anti-virus software.

Background of Android Public Storage

Android provides 5 options for an app to store data, including shared preferences, internal storage, external storage ("public storage" referred in this paper), SQLite databases and remote storage. In this paper, we focus on public storage since the protection enforced is weaker than the other options. Evolution. Before Android 3.0, external storage only includes real external SD card. Since the size of built-in Flash memory is limited in the early stage of Android, external storage is a preferable option for app developers, especially to store large files, like audio files and images. In recent years, we have seen a significant growth of the size of built-in Flash memory (e.g., 64GB), and it turns out internal storage can also hold large files. However, app developers still prefer to consider external storage to hold app's data for two reasons: First, the Android devices with limited built-in Flash memory are still popular, especially in less developed countries or areas; second, the external and internal storage run with different model and are operated with different APIs, which forces the developers to make unneglectable changes if switching to internal storage.

To maximize the use of its storage without incurring additional overhead to developers, Android adopts FUSE [START_REF]Filesystem in userspace[END_REF] to emulate a sdcard daemon (mounted as /data/media) inside userdata partition (/data). File operations on this partition resembles the ones on external SD card and we consider both as public storage. Access control model on external storage. Access to external storage is protected by various Android permissions, however, our attack aims to retrieve users' private information and hence we only elaborate the details of read access. Before Android 4.1, there is no permission restricting read operations on public storage. READ permission is added to Android since then, and an app has to be granted with such permission to read files on public storage. This permission is supported through attaching a Linux GID sdcard r to all the files on public storage and an app (corresponding to a process in Linux) has to be granted with GID sdcard r as well before visiting any file there. A fundamental issue with this model is that there is no finer-grained control over what files are accessible to one app if sdcard r is granted, which exposes one app's private data to all other apps. It is worth noting that the permission WRITE MEDIA STORAGE introduced from Android 4.4 enforces finer-grained control over write operations, but nothing has been changed for read operations.

Survey on information leaks from public storage

It is true that some app-private data is not sensitive. However, the model of letting apps write their private data to public storage relies on a strong assumption that app developers can make right decisions to tell sensitive data from non-sensitive ones. In this section, we present a survey of the information leaks through app-private data stored on public storage, which shows that such an assumption is problematic. The survey includes two parts: the first is a detailed examination on 17 most popular apps, and the other is a more general and large scale study.

Investigation on popular apps

What apps have been surveyed. According to our adversary model, the attackers are interested in privacy attacks over app-private data, so we have selected 17 most popular apps from three categories: "social networking", "instant messaging" and "online shopping&payment", which are believed to be more likely to touch users' sensitive information. The categories, versions and total users of these apps are shown in Table 1. How to check app-private data. These apps are installed on three Samsung Galaxy S3 mobile phones. Then we manually simulate three different users on three phones, including account registration, adding good friends, sending message, and etc. Finally, we check the public storage, search sensitive data for each app and classify them. How the information is leaked. By studying the popular apps, we found 10 of them leak various sensitive information through app-private data on public storage, as shown in Table 2. Such information is leaked in different forms which are discussed as below, and the details are elaborated in Appendix A.

Leak through text files. Some apps store user's profile into a text file. For example, Viber directly saves user's name, phone number into a plain text file without any Leak through file names. We found several apps organize data related to the user or her friends into a dedicated file named with sensitive or non-obvious sensitive information. For example, a file created by Weibo is named as user's UID, WhatsApp stores user's friends photos with that friend's phone number as file name. They seem meaningless but could have significant privacy implications when combined with other public information, i.e., the owners of the phone numbers acquired from WhatsApp can be found by comparing these acquired portraits with photos from user's social networks. Leak through folder names. Some apps use account name as folder name directly, like Renren and Momo. While KakaoTalk will create folders with the same name in both two users' phones if they chat with each other, files (i.e., photos) sent to each other will be saved in the folder and also with the same name. Such a naming convention reveals the connections among people, and even can be leveraged to infer user's chat history.

Leak through photos. The social networking apps usually cache user's profile photos in public storage, like LinkedIn in our study. The photo itself is non-sensitive if without knowing who is in the photo, however, our study shows that user's LinkedIn profile photo can be linked to her identity by Google image search, as shown in Fig. 1.

Leak through specific patterns. We could use the command /system/bin/sh -c grep -r @xxx.com path to match and extract email addresses from files in public storage. If the files are stored by apps, the corresponding emails are very likely belong to the phone's owner. It is worth noting that the email found by grep command in Table 2 is from a log.txt file left by Renren old version (5.9.4).

What information has been leaked. As shown in Table 2, there is indeed some important sensitive information leaked through the app-private data. To better understand the privacy implication of such leaks, we use Personal Identifiable Information (PII) [START_REF] Mccallister | Guide to protecting the confidentiality of personally identifiable information[END_REF], a well-known definition for private data, to classify and evaluate the leaked information.

We defined two categories of sensitive data, Obvious sensitive data and Non-obvious sensitive data, by refining the concept of PII as below:

-Obvious sensitive data. It contains identifiers in PII related to user's real-world identity, including full name, phone numbers, addresses, date of birth, social security number, driver's license id, credit card numbers, and etc. -Non-obvious sensitive data. It contains identifiers in PII related to user's virtualworld identity and also her friends' information. The virtual-world identifiers include email addresses, account name, profile photos, and etc.

How to infer user's identity. As shown in Table 2, attackers can exploit the sensitive data left by several apps to infer user's identity information. For example, A user's identity can be acquired from her personal homepage by using her Renren UID, Weibo Username/UID, Linkedin profile photo. Moreover, We could find someone on Facebook with a high probability by the email addresses extracted from public storage and also the usernames acquired from other apps, since people prefer to use the same username and email address among their various social networking apps [START_REF]like' it or not, sharing tools spur privacy concerns[END_REF].

We divided the apps into three categories with privacy protection level from high to low, and shown in Table 3. Apparently, leaking obvious sensitive data should be prohibited and requires immediate actions from the app developers and Android development team. While our study also demonstrates the feasibility to infer obvious sensitive data from non-obvious ones, therefore the latter should also be well protected.

Investigation on apps with a large scale

Our study on the popular apps indicates that the sensitive information of device owners could be leaked even from very popular apps. To understand the scale of this problem, we launched a large-scale study on more apps through a customized static analysis tool. Specifically, we first decompile app's apk to smali code using Apktool [START_REF]Apktool[END_REF] and then search for APIs or strings which indicate storing private data to public storage. Our analysis is conducted on smali code instead of decompiled Java code (done by [START_REF] Gibler | AndroidLeaks: automatically detecting potential privacy leaks in android applications on a large scale[END_REF][START_REF] Au | Pscout: analyzing the android permission specification[END_REF]) since information could be lost during the code transformation of latter approach. Dynamic analysis, though usually producing more accurate results, is not used here, because it takes long time for even one app to reach proper states (e.g., registration, sending messages, etc.). Again, we focus on the categories described in Table 1 and totally select 1648 different apps from our app repository (34369 apps) for analysis.

Ultimately, our tool should be able to classify the information kept on public storage as sensitive or not, which turns out to be very challenging or nearly impossible without intensive efforts from human. Whether a piece of data is truly sensitive to the device owner depends on the context. We therefore simplifies this task and only checks whether an app intends to store sensitive information on public storage. Particularly, if the names of the private folders or files on public storage created by an app contain specific keywords, it is considered as suspicious. Our keywords list include log, files, file, temp, tmp, account, meta, uid, history, tmfs, cookie, token, profile, cache, data, and etc., which are learned from the problematic apps and are usually associated with sensitive content. Some keywords (e.g., cache and data) appear to be unrelated to sensitive information, but they turn out to be good indicators based on our study, as shown in Appendix A.

For each app, we build a control flow graph (CFG) based on its smali code to confirm whether the "sensitive" data is truly written to public storage. We demonstrate

Table 4. Methods of accessing public storage

Category Methods

API Call

getExternalFilesDir(), getExternalFilesDirs() getExternalCacheDir(), getExternalCacheDirs() getExternalStorageDirectory(), getExternalStoragePublicDirectory() Hardcoded Path "/sdcard", "/sdcard0", "/sdcard1" our approach as follows: we start from extracting the method block in smali code by finding the texts between keywords .method and .end method. Next, we select instructions beginning with keywords invoke-static, invoke-direct, invoke-virtual to construct CFG for the method. Then, we check if the methods listed in Table 4 are used to access public storage and whether files or folders are created there (by inspecting methods like mkdir and FileOutputStream). Finally, we check whether the strings sent to these methods contain keywords in our list. Each function f in the CFG will be marked based on the three criteria. To notice, we do not consider special methods like touch as they are also used for other purposes by developers.

We implemented Algorithm 1 on the marked CFG, the depth parameter of the DFS procedure was set as 3 empirically, since it resulted in reasonable resources consumption and also yielded high accuracies when examining the known problematic apps. The results show that 497 apps from the 1648 apps being analyzed intend to write some "sensitive" app-private data on public storage, which indicate that the privacy leakage problem revealed in this paper is widely exist among apps. However, this method may lead to false positives when an app stores "sensitive" data in other places. To have a verification, we randomly chose 30 apps from the suspicious apps, and manually checked them. We found that as large as 27 apps truly wrote "sensitive" app-private data on public storage, suggesting this simple static method is valid. This result also suggests there are common patterns among app developers on dealing with sensitive data.

Inferring user's location

In this section, we present an example attack based on the non-obvious sensitive information extracted from app-private data. We begin with a brief introduction to the design of a malicious Android app called SAPD ("Smuggle App-Private Data"), followed by detailed description of the attack.

Attack preparation

The weakest part of the malicious app might be the potential outstanding network traffic footprint, especially for users with limited 3G plan. We implemented two optimizations in our app prototype SAPD to get around this limitation. First, try to minimize the uploaded data since it is reasonable to assume that attackers have already studied the vulnerable apps. Another optimization is to upload data only when Wi-Fi network is available. Instead of using WiFiManager which needs to require ACCESS WIFI STATE permission, SAPD is able to know whether a WiFi network is connected or not by for all element e in f.mark do 17:

condition(e) = true; 18:

end for 19:

for all callee ce of f do 20:

DF S(ce, depth -1); 21:

end for 22: end procedure reading public files (procfs), since Android puts the parameters of ARP in the file /proc/net/arp and other wireless activities in /proc/net/wireless. In addition, to minimize the possibilities of being caught due to suspicious CPU usage or abnormal battery consumptions, SAPD will only reads and uploads filtered useful data, and it will never perform any kind of intensive computations.

Attack framework

Location of a phone user is considered as sensitive from the very beginning and there are already a lot of research works on inference attacks and also protections [START_REF] Srivatsa | Deanonymizing mobility traces: Using social network as a sidechannel[END_REF][START_REF] Zang | Anonymization of location data does not work: A large-scale measurement study[END_REF][START_REF] Zhou | Identity, location, disease and more: Inferring your secrets from android public resources[END_REF]. In recent years, location-based social discovery (LBSD) is becoming popular and widely adopted by mobile apps, i.e., WeChat and Momo investigated in this paper. Though apps adopt some protection mechanisms, i.e., only distance between the user and the viewer is revealed, such location inference attacks are still feasible. Our attack also aims to infer user's location from LBSD networks, but we make improvements since the profile information is extracted from victim's phone, thus leads to a realistic threat. As a showcase, we demonstrate our attack on WeChat app.

The LBSD module in WeChat is called "People Nearby", through which, the user can view information of other users within a certain distance, including nick name, profile photo, posts (called What's Up), region (city-level) and gender. Though WeChat UID is not stored on public storage, QQ UID and phone number are stored instead, they are bound to WeChat account and has to be unique for each user. As described in section 4.1, this information has been collected by SAPD and sent to one of our servers (denoted as S 1 ). These servers are installed with emulated Android environment for running WeChat app. S 1 will first create a database by querying the server of Tencent (the company operating WeChat) for profile information. Then, the attacker needs to instruct another server (denoted as S 2 ) to run WeChat using fake geolocations, to check People Nearby and to download all the profile information and their corresponding distances. The profile information stored on S 1 is then compared with the grabbed profile information (downloaded by S 2 ) in another server (denoted as S 3 ) followed the steps shown in Fig. 2. If a match happens, S 2 will continue to query People Nearby for two more times using different geolocations (faked) to get two new distances. Finally, the target's location can be calculated using the three point positioning method. We elaborate the details of two key steps as below: Getting Users' Profile Information. The attacker uses QQ userid or phone number to query Tencent server for user's profile information. The returned profile consists of 5 fields: nick name, profile photo, posts (What's Up), region and gender. Our task is to assign the location information for each profile. Unfortunately, this profile is updated according to the user's location. What we do here is to frequently retrieve profiles and distances information by faking to different locations. A challenge here is to extract the profiles and distances from WeChat, as there is no interface exposed from WeChat to export this information. After we decompile its code, we found the app invokes an Android API setText from android.widget.TextView to render the text on screen whenever a profile is viewed. We therefore instrument this API and dump all the texts related to profiles into log files. This helps us to extract three fields of a profile, including Region, Nickname and What's Up and also its corresponding distance.

Comparing process. The comparison processes performed in S 3 are shown in Fig. 2, which is based on such an observation: People can be distinguished from each other by the three fields (Region, Nickname and What's Up). Note that we ignore the special case that different people have the same values of the three fields, since such a possibility is very low due to we require that any of the three fields should not be blank. To avoid the situation that people may have changed her Nickname or What's Up information before our comparison, we will update her profile by querying Tencent server if only one of them is matched with the data stored in our database. An app called "Fake GPS location" [START_REF]Fake gps location[END_REF] is leveraged to fake server's GPS to different places. For the densely populated places, we added several more anchor points, since People Nearby only display limited amount of users (about 100). In addition, we use a monkeyrunner script to automatically refresh People Nearby. For each point, to load all the people's profile information, the script will scan people's profile one-by-one through triggering event KEYCODE DPAD DOWN until loading the last one's information. This process has to request data from Tencent. To avoid raising alarm from Tencent, the script sleeps a while before changing to a new anchor point. Attack evaluation. We evaluate our attack on 20 participants. Each participant has installed WeChat with People Nearby turned on (so their profiles will be open to view). Our attack successfully revealed the live locations for 17 participants and have been verified by them. Note that some of the inferred locations are not exact where the user stays, but they are all within the acceptable range, i.e., in a specific residential district.

Mitigations

We demonstrate the feasibility of our attacks through the examples above. Without probable countermeasures, more devastating consequences would be caused. Hence, we suggest two approaches enforced by app developers and Android system. The details are described below: Fixing by app developers. The first suggestion is to ask developers to write ALL appprivate data to internal storage, which can only be accessed by the folder owner. Though the threat is mitigated, app's functionality could be interrupted when running on devices with limited capacity of internal storage. Moreover, millions of developers are expected to make such change and it is hard to be achieved in the near future. Patching Android system. On the contrary, modifying the Android system and pushing the upgrades to users' devices would be a more practical way to mitigate the security issues. For this purpose, we propose to augment the existing security framework on public storage by instrumenting the API checkPermission(), the framework is described as below: Architecture. We design a new module named ownership checker, which works on Android Middleware layer and can achieve mandatory access control (MAC) for appprivate data. Specifically, when the targets are public resources, like music directory, the access is permitted. When the target files are placed under app's private folder, the access is only permitted when the calling app matches the owner. Otherwise, ownership checker will return PERMISSION DENIED even if the app has been granted READ or WRITE permission. To enforce such rule, we create a system file owner checker.xml storing the mapping between apps and resources, similar to Access Control Lists (A-CL) of Ext4 file system. The system code within checkPermission() is modified to read the mapping and check the ownership before actual file operations happen. An exception will be thrown if mismatch happens. Alternatively, we could leverage other frameworks like SEAndroid [START_REF] Seandroid | [END_REF] to enforce MAC and protect app-private data. Ownership inference. The ownership mappings between apps and resources need to be established. This task turns out be non-trivial, since we have to deal with the case that the public storage has already stored apps' data before our module is installed and the owner of data is not tracked therefore. To fix the missing links, we exploit the naming convention: an app usually saves data to a folder whose name is similar to its package name, which can be acquired from packages.xml under /data/system). As a starting point, we initialize the mappings by scanning all the resources. For a given resource, we assign the owner app if the resource location and app package name share a non-trivial portion. To notice, this initialization step could not construct the mapping when an app stores the data in a folder whose name is irrelevant. The access to such resources will be blocked, and we provide an interface for users to manage the ownerships. A new mapping will be added if the ownership is assigned by the user. To reduce hassles to users, user-driven access control model [START_REF] Roesner | User-driven access control: Rethinking permission granting in modern operating systems[END_REF] can be integrated to automatically assign ownership based on user's actions.

Discussion

Why does the problem persist? In the early stage, Android phone has limited onboard Flash memory (only 256MB for the first android phone, HTC Dream). On the other hand, its storage can be expanded through large volume external SD card, which is usually shipped together. This storage model forces app developers to differentiate sensitive data from non-sensitive data and save the latter (most of the data) to public storage. App developers follow this practice even after recent changes on Android's storage model which offers more flexible storage options (i.e., the sdcard dameon (fused) and userdata /data share the same partition dynamically). Limitations of app study. We built a tool running static analysis on app's smali code and use a set of heuristics to determine if the app saves "sensitive" app-private data to unprotected public storage. This simple tool identifies a large number of potentially vulnerable apps and shows reasonable accuracy from our sampling result. However, it is inevitably suffers from false negatives (e.g., the file name does not contain the keywords we used) and false positives (e.g., the information saved is not sensitive). We leave the task of building a more accurate detector as future work.

Related Work

Attacks like stealing users' chat history [START_REF]Whatsapp user chats on android liable to theft due to file system flaw[END_REF] have been proved feasible in the real world. However, these attacks usually depend on certain vulnerabilities identified from the victim apps, while our attacks exploit a more general problem related to Android's storage model. In addition to steal user's sensitive information directly, a lot of research focused on inferring user's location. The authors of [START_REF] Srivatsa | Deanonymizing mobility traces: Using social network as a sidechannel[END_REF] showed a set of location traces can be de-anonymized through correlating their contact graph with the graph of a social network in spite of the data has been obfuscated. Based on a large-scale data set of call records, Zang et al. [START_REF] Zang | Anonymization of location data does not work: A large-scale measurement study[END_REF] proposed an approach to infer the "top N" locations for each user. A recent work [START_REF] Zhou | Identity, location, disease and more: Inferring your secrets from android public resources[END_REF] by Zhou et al. targeted to infer information of users from more perspectives, including identities, locations and health information.

To defend against the existing or potential attacks tampering user's privacy, a bunch of defense mechanisms have been proposed. Ongtang et al. proposed a finer-grained access control model (named Saint) over installed apps [START_REF] Ongtang | Semantically rich applicationcentric security in android[END_REF]. FireDroid [START_REF] Russello | Firedroid: hardening security in almost-stock android[END_REF], proposed by Russello et. al., was a policy-based framework for enforcing security policies on Android. Roesner et al. proposed user-driven access control to manage the access to private resources while minimizing user's actions [START_REF] Roesner | User-driven access control: Rethinking permission granting in modern operating systems[END_REF]. Besides, efforts have also been paid on code analysis to block the information leakage. Enck et al. developed TaintDroid [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] to prevent users' private data from being abused by third party apps.

It is known that public storage on Android is insecure, due to its coarse-grained access model. Therefore, it is highly recommended that the sensitive data should be avoided from saving there. In this paper, we carry out a large-scale study on existing apps on whether app developers follow this rule and the result turns out to be glooming: a significant number of apps save sensitive data into the insecure storage, some of the problematic apps are even ranked top in Android market. By exploiting these leaked data, it is possible to infer a lot of information about the users, drastically violating users' privacy. We urge app developers to fix the vulnerabilities. Besides, we also propose an approach to patch Android system with MAC support and envision it could mitigate the threat in the short term.

Fig. 1 .

 1 Fig. 1. The result of searching a user's Linkedin profile photo.

Fig. 2 .

 2 Fig. 2. The diagram of profile information comparison.

Table 1 .

 1 The categories, versions and total users of the popular apps

	Category	App Name Installed Version	Total Users (Millions)
		Facebook 13.0.0.13.14 900M
		Instagram 6.2.2	100M
		Twitter	5.18.1	310M
	Social networking	Linkedin Vine	3.3.5 2.1.0	300M 40M
		Weibo	4.4.1	500M
		Renren	7.3.0	194M
		Momo	4.9	100M
		WhatsApp 2.11.186	450M
		Viber	4.3.3.67	300M
		Skype	4.9.0.45564 300M
	Instant messaging	Line KakaoTalk 4.5.3 4.5.4	350M 100M
		Tencent QQ 4.7.0	816M
		WeChat	5.2.1	450M
		EasyChat 2.1.0	60M
	Online shopping &payment	Alipay	8.0.3.0320	300M

Table 2 .

 2 Sensitive information acquired from the popular apps

	Sensitive Information App Name	Content/Remarks
	User Identity	Weibo, Renren Linkedin	UID User's profile photo
	Phone Number	Viber, Alipay, EasyChat	User's phone number
	Email	Weibo, Renren	Registered email
	Account	Tencent QQ,Viber,Renren,Momo,Weibo UID WeChat QQ UID / Phone number
		EasyChat	Call records
	Connection	Linkedin KakaoTalk	Profile photos of friends Chatting buddies
		Renren	Friends' UIDs
		WhatsApp	Phone numbers of friends

encryption. User's username, email address 4 are stored by Weibo in a file named by the user's UID. Some apps also keep text logs which reveal quite rich information, i.e., EasyChat keeps call records in a file, so caller's number, callee's number and call duration can be easily recovered by simply parsing each record.

Table 3 .

 3 Privacy protection level of the 17 popular apps

	Privacy Level App Name	Issues
	Facebook, Twitter, Instagram, Skype	-
	Line, Vine, WeChat	Audio files without encryption
	WhatsApp, Linkedin, Viber, KakaoTalk, Momo	Detailed problems are
	Tencent QQ, Alipay, Renren, Weibo, EasyChat	shown in Appendix A

  Algorithm 1 : Detecting suspicious apps

	Input: Class set C, Keyword P atterns set KS, P ath set P A, W rite set W A
	Output: bool sensitive
	1: for class c in C do 2: for f unction f in c do	Each f has been marked f ollowing the rules
	3:	condition.clear();
	4:	DF S(f, depth);
	5:	if condition == U nion(KS, P A, W A) then	All the criteria are met
	6:	return true;		M arked as suspicious app
	7: 8: 9: end for end if end for 10: return false;
	11: 12: procedure DF S(f unction f, int depth)
	13:	if depth == 0 then
	14:	return;
	15: 16:	end if

If the user uses her email to register Weibo account. The user also can use phone number to register an account.

We use ... to represent part of the full path since sometimes the full path is too long.

Acknowledgments. We would like to thank the anonymous reviewers for their valuable comments. This work was supported by the Direct Grant of The Chinese University of Hong Kong with project number C001-4055006.

A The details of user private data Viber. The text file .userdata in .../.viber/ 5 reveals lots of user's information, including real name, phone number, and the path of user's profile photo. WhatsApp. The user's profile photo is stored in .../.shared/ with file name tmpt. The profile photos of user's friends are saved under .../Profile pictures/, and they are named by profile owners' phone numbers without any obfuscation. Linkedin. This app cache the photos into the directory /Android/data/.../li images/. The user's profile photo can be distinguished by file size and modified time. KakaoTalk. If user A has chatted with user B, the app will create a content folder with the same name in both users' phones, under the path /Android/data/.../contents/. The files, i.e., photos, on the two phones also have the same name, size and the same path. Tencent QQ. User's account can be got from log files in the path .../mobileqq/. Weibo. A file named as user's UID is saved under the path .../page, and we can acquire the user's username and her email address. User's username and UID can be leveraged to access her homepage by constructing specific URLs, i.e., http://www.weibo.com/UID. Alipay. User's phone number can be obtained from the meta file in .../cache/, it also points out the other file which discloses the user's phone number. Renren. A folder named by user' UID is stored in /Android/data/.../cache/. Even user' visit histories are also stored in this folder, which contains the name, UID of user's friends. The audio files are named as the format UID+hash value. We can find the user's personal home page by the URL http://www.renren.com/UID in a browser. Momo. A folder named as user's account is saved in .../users/. By the account, we can not only get her profile information, but also infer her location. EasyChat. The file pjsip log.txt in /Yixin/log/ contains all the call records information. Audio files. Instant message apps, like WhatsApp, Line, WeChat, Tencent QQ, and KakaoTalk, store the audio files into public storage without encryption.


Konstantin Knorr
email: knorr@hochschule-trier.de

David Aspinall
email: david.aspinall@ed.ac.uk

Maria Wolters
email: maria.wolters@ed.ac.uk

On the Privacy, Security and Safety of Blood Pressure and Diabetes Apps

Mobile health (mHealth) apps are an ideal tool for monitoring and tracking long-term health conditions. In this paper, we examine whether mHealth apps succeed in ensuring the privacy, security, and safety of the health data entrusted to them. We investigate 154 apps from Android app stores using both automatic code and metadata analysis and a manual analysis of functionality and data leakage. Our study focuses on hypertension and diabetes, two common health conditions that require careful tracking of personal health data. We find that many apps do not provide privacy policies or safe communications, are implemented in an insecure fashion, fail basic input validation tests and often have overall low code quality which suggests additional security and safety risks. We conclude with recommendations for App Stores, App developers, and end users.

Introduction

Mobile health (mHealth) applications cover all areas of health IT, from health information databases to personal electronic medical records. They are very popular-according to appbrain.com, in December 2014, Google Play had 21,457 apps in the medical category and 3% of these have been downloaded more than 50,000 times. mHealth apps for Android and iOS are currently largely unregulated [START_REF] Daniel | Regulatory arms race: Mobile-health applications and agency posturing, the[END_REF]. Many of these apps are written by individuals or small companies who see a market niche, or by pharma and drugstore companies that seek to provide added value and collect information about their customer base [START_REF] Wolters | The minimal effective dose of reminder technology[END_REF].

Around 20% of medical apps cost money, on average US $9.78, making them the most expensive category. This suggests that users attach a high value to mHealth apps. But does this buy data protection?

Many mHealth apps handle highly sensitive data that require particular privacy and security precautions [START_REF] Kotz | A threat taxonomy for mHealth privacy[END_REF]. For example, insurers demand full disclosure of pre-existing conditions. If insurers find mHealth data that suggest an unreported condition, the applicant may be denied coverage or their policy may be downgraded.

In this paper, we examine how far a representative sample of 154 mHealth Android apps for two common long-term conditions, diabetes and hypertension, succeed in ensuring the privacy, security, and safety of the health data entrusted to them. While previous work has considered relatively diverse samples of 40-50 mHealth apps at once [START_REF] Adhikari | Security and privacy issues related to the use of mobile health apps[END_REF][START_REF] Michael | Technical analysis of the data practices and privacy risks of 43 popular mobile health and fitness applications[END_REF][START_REF] He | Security threats to Android apps[END_REF][START_REF] He | Security concerns in Android mHealth apps[END_REF], we focus on a the management of long-term conditions which require users to regularly track key health indicators. Such conditions are an ideal mHealth use case. Well-designed apps allow users to enter data when and where they choose, to communicate with carers and health care professionals, and to discover trends and patterns in their own medical data.

Contributions. We introduce a novel method that takes into account the files contained in the APK (i.e., the downloaded package of the app), the dynamic behaviour of the installed app, and the app's privacy policy. We also consider input validation and source code quality. This comprehensive evaluation goes beyond previous studies, which mainly examined permissions and network traffic. In addition, our clear focus on long-term conditions allows an in-depth discussion of the specific privacy concerns.

The rest of the paper is structured as follows: Sect. 2 introduces mHealth apps and the categories we examine in detail; we explain the high-level functionality they provide, and discuss potential privacy threats. Sect. 3 describes the proposed methodology, while Sect. 4 gives the corresponding results and its discussion following the structure of the methodology. Suggestions for improving the current privacy issues of mHealth apps and future work conclude the paper in Sect. 5.

Hypertension and Diabetes

We focus on two long-term health conditions, hypertension and diabetes. People with hypertension suffer from chronically elevated blood pressure, which increases the risk of many serious illnesses including cardiovascular disease, stroke, and chronic kidney disease. Diabetes is a group of diseases that are characterised by elevated blood sugar levels. Controlling blood sugar is therefore the main aim of treatment.

Both conditions can be tracked using a simple numerical indicator, blood pressure (hypertension) and blood glucose level (diabetes), both are highly prevalent in the population3 , and for both conditions, self-monitoring is an important part of clinical management [START_REF] Labeit | Changes in the prevalence, treatment and control of hypertension in Germany? A clinical-epidemiological study of 50.000 primary care patients[END_REF][START_REF] Tamayo | Diabetes in Europe: an update[END_REF].

The key function of a monitoring app is to capture a reading of the indicator measure at a given point in time. Fig. 1 shows a sample user interface for manual input of hypertension with a basic set of fields. Fields may not have a clearly defined use, such as "My Item" in our example, and others can contain free text, such as "Note".

Typical additional functionality includes providing reminders; data analysis and reporting; and backup, sharing, and export of recorded data. Some apps support several user profiles, while others include functionality for emergency texts and telephone calls. The main menu screen of Diabetes Journal (com.suderman.diabeteslog, Fig. 2) shows how this functionality is typically implemented. "Averages" and "Charts" cover the data analysis and reporting function, the "Calendar" supports reminders, "Entries" leads to an entry screen for blood glucose values, and "Profiles" allows users to switch profiles. For both blood pressure and blood glucose levels, there are well documented clinical guidelines that govern their interpretation, such as those issued by the UK National Institute for Clinical Excellence (NICE). But integrating values collected using mHealth apps into clinical management is difficult. As long as most apps rely on manual data entry [START_REF] Donna | The promise and peril of mobile health applications for diabetes and endocrinology[END_REF], data quality is questionable, especially given that, as we will see in Sect. 4, apps may fail to perform basic validity checks on the health data they receive from the user.

Privacy threats and relevant regulation

In the US, the Health Insurance Portability and Accountability Act (HIPAA) sets legal security and privacy standards for electronically transmitted health information; in the EU, there are diverse country-specific laws that need to be respected [START_REF] Avancha | Privacy in mobile technology for personal healthcare[END_REF]. Devices that collect measurements which are used for monitoring, treatment, or diagnosis of health conditions are medical devices and these are regulated by the Food and Drug Administration in the US. The key medical device directive in the EU is Directive 93/42/EEC, which was updated in 2007.

Smartphone apps for monitoring diabetes and hypertension, in particular those that do not directly receive data from a validated blood pressure or blood glucose meter, fall into a grey area that is not adequately covered by current standards [START_REF] Helm | Privacy and mHealth: How Mobile Health 'Apps' Fit into a Privacy Framework Not Limited to HIPAA[END_REF][START_REF] Daniel | Regulatory arms race: Mobile-health applications and agency posturing, the[END_REF], and finding a good balance between encouraging innovation and ensuring privacy is challenging [START_REF] Wang | The HIPAA conundrum in the era of mobile health and communications[END_REF].

Several frameworks have been proposed for classifying the threat that mHealth applications pose to the privacy of health information (e.g. [START_REF] Kotz | A threat taxonomy for mHealth privacy[END_REF]). Most of these focus on information that would make the patient identifiable, in particular ID or social security numbers. While many self-management apps do not collect those data, they do often store name, gender, and date of birth. Privacy threats also depend on the type of mHealth app [START_REF] Helm | Privacy and mHealth: How Mobile Health 'Apps' Fit into a Privacy Framework Not Limited to HIPAA[END_REF], and on the condition that is being managed.

Threat scenarios for mHealth apps in use

Fig. 3 shows a smart phone with mHealth apps installed. Medical data like blood pressure or glucose values can be input by the user or, less commonly, received from external medical devices via Bluetooth or NFC. The smartphone stores the app's data internally either in a database or the internal file structure. The SD card is used for database backups and restores, and to export reports or selected medical data. Mobile networks are used for emergency SMS and calls.

Five types of servers are potentially connected to the smartphone and app. The App Shop is used to initially download and possibly pay for the app. Subsequently, connections for licensing and billing e.g. for in-app purchases or upgrades of the app are maintained. Many of the apps display ads, which are provided by Ad Servers, most prominently Admob by Google. App developers also use Analytics such as Google Analytics to track user behaviour. Many apps allow to upload, backup or synchronize the data to Social Media, Storage Services or a dedicated external App Web Server provided by the app developer or cooperating third parties. This server may provide interfaces to other parties like insurance companies, doctors, or hospitals. Most apps allow sending e-mails with medical data. This is typically done via an Android e-mail "intent" which connects to a (implicitly trusted) email app on the phone. Overall, the complexity in this picture emphasises the privacy challenges faced by a user trying to keep control over his/her medical data.

Methodology

We selected mHealth apps for diabetes and blood pressure which: (1) had an English or German user interface; (2) would run on a Google Nexus 7 test device with Android 4.4.2 installed; (3) had over 10,000 downloads (for free apps) or over 1,000 (for paid). Most apps came from the medical category and were specifically developed for diabetes and blood pressure monitoring. We ended up with 154 apps in the final test set (55% diabetes, 35% blood pressure, 10% both) that were installed on the Nexus 7. The most popular apps are My Heart (com.szyk.myheart) and BP Watch (com.boxeelab.healthlete.bpwatch) which each have between one and five million downloads. 4

Our method

The investigation has four parts: (A) static analysis; (B) dynamic analysis; (C) web server security and (D) privacy policy inspection. Fig. 4 shows a picture of the method. The results were gathered in a database. Static analysis was applied to the full set of 154 apps; other analysis stages were applied to subsets. (A) Static analysis. The static analysis is based on the information contained in the APK file, including the manifest and the compiled code (in the file classes.dex). Results for the top 10 apps are shown in Table 1. We used Mal-loDroid [START_REF] Fahl | Why eve and mallory love Android: An analysis of Android SSL (in) security[END_REF] to identify faulty SSL usage, such as the failure to check certificate chains; this would allow man-in-the-middle attacks which enable an attacker to access all medical data transmitted. OpenSSL was used to extract certificate information and find certificates with poorly chosen cryptologic parameters [START_REF] Allix | A Forensic Analysis of Android Malware: How is Malware Written and How It Could Be Detected?[END_REF].

We checked Android content providers and debugging flags using Drozer. The ContentProvider class allows sharing data between applications, with its own access control model. A careful implementation will prevent unauthorized access to sensitive data. When the debug flag for Android is set, the application can be debugged, even when running on a device in user mode, thereby possibly revealing medical information.

Addons Detector was used to identify and classify the add-on libraries used by the apps. Health apps were scanned for malicious code, security vulnerabilities and privacy failings using Snoopwall Privacy App, Clueful, AVG Antivirus Security, AVAST, McAfee, and the Recap vulnerability scanner.

We assessed code quality by using FindBugs to count the number of likelybug patterns occurring in apps; high numbers indicate a likely poor code quality, which suggests possible unreliable behaviour, giving additional security and safety risks.

(B) Dynamic analysis. We analysed the 72 most frequently downloaded apps, including all those with web interfaces to external servers. We set up Facebook, Twitter, Dropbox, and Gmail accounts for a patient for whom some values were out of the physiologically normal range. The patient was 170 cm tall, weighed 99 kg, had dangerously high blood pressure (200 mmHg/120 mmHg), a physiologically improbable heart rate (333 bpm) and a blood glucose level of 111 mmol/L, which is lethal and indicates that the user confused mg/dL with mmol/L.

We generated Facebook, Twitter and Dropbox accounts for the patient and tested all available export routes for the data. We investigated whether abnormal and illegal inputs were accepted, and how exported data was stored or transmitted. Using the Android debugger command adb pull and the adb logcat command, we tested whether the backups or log data contained unencrypted medical data. We also established whether the app included a feature to erase all stored medical data, whether there was a privacy policy for the app, and whether the permissions required by the app were reasonable.

(C) Web server connection. For apps that can interface with a dedicated web server (n=20) using a user account for uploading data, we checked whether a sensible password policy was enforced on the web site and tested the Web Server connection. We recorded the URLs used for connections and noted if they used a secure transport (https:). We recorded traffic to see if passwords or medical data in textual or graphical form could be sniffed in clear text.

(D) Inspection of privacy policies. Only 19% of apps in (A) have a privacy policies. This is far lower than the proportion found by Sunyaev et al. [START_REF] Sunyaev | Availability and quality of mobile health app privacy policies[END_REF] in their survey of the 600 most commonly used apps, where 30% of all apps had some form of privacy policy. Since storage of medical data on an external server further stresses privacy concerns, we limited the test to the same apps as in (C). We assessed privacy policies on basic information provided (URL to privacy policy, length in words, version, and country of origin), completeness (information about the OECD criteria accountability, security safeguards, openness, purpose, individual participation [START_REF]OECD guidelines on the protection of privacy and transborder flows of personal data[END_REF]), and invasiveness (possible use for other purposes, storage by third party, potential to be passed on to third parties) by asking basic questions and trying to find answers in the documents.

Results and discussion

Table 1. Analysis results for the top 20 downloaded apps. Columns: lack of a privacy policy, existence of MalloDroid errors, debug flag enabled, missing access protection of content provider, poor certificate parameters, usage of ad and analytics addons, more than 300 FindBugs errors, usage of more than 5 Android permissions, lack of input validation for input data, absence of a wipe feature. Tables 1 and2 give an overview of our results. In both Tables, × is used to indicate a problem, and the score is the number of problems found.

We found that paid apps tend to use fewer ads (even though some keep the ad libraries code) and offer more functionality (like e-mail or SD card export). Concerning the other tests, we could not find major differences. Especially comparing "twin apps" (free and paid version of same app) produced similar results.

Static analysis. The number of permissions used ranges from 0 (28 apps) to 17 with an average of 4.35. The most frequently requested Android permissions are INTERNET (126 times), followed by WRITE EXTERNAL STORAGE (117), and ACCESS NETWORK STATE (109). The permission BLUETOOTH is used 18 times, NFC 3 times. Of the 126 apps using the INTERNET permission, 15 do not correctly verify certificates or certificate paths, allowing for MITM attacks. Six apps had the debuggable flag set to "true" in their manifest, possibly allowing debug connections to inspect medical data. 17 apps use content providers that were accessible to other apps on the device, and four revealed medical data to all other apps on the device.

Apps are infested by ad and analytic addons on a large scale. The addons in the Advertising (74 apps, Admob being dominant) and Analytics (27 apps, Google Analytics dominant) category have been identified as a major privacy problems transferring device IDs and other data. Eight apps use Facebook or Twitter addons.

All apps used self-signed certificates, although using an acknowledged CA could establish additional trust. Certificates of 4 apps have a life time of ∼1,000 years, another 6 of ∼100 years. Most of them are valid for ∼30 years. The majority use SHA1, and only 17% the more secure SHA256. Only 40 certificates give more information than the name of the developer, thereby not establishing additional trust by adding more detailed information.

The Clueful tool gave a privacy score of 56 out of 100 for the apps on the test device and identified no high risk app and 57 moderate risk apps. The ranking is purely based on permissions. Snoopwall also just lists permissions for each app. Recap is a vulnerability scanner based on 1,800 CVE numbers. All its findings were OS related. We additionally checked if the apps in our test set in its current or earlier version are listed in the National Vulnerability Database http://www.nvd.org (NVD) and found no entries. AVG classified com.stevenmz.BloodPressureDiary as malware and MMSL.BGGlucoDiary as "Potentially Unwanted Program" without giving a detailed explanation 5 . Avast and McAfee did not find any malware, privacy or security issue. Dynamic analysis. 43 of 50 blood pressure apps allow users to enter alarmingly high blood pressure values of 200 / 120 mmHg with the current time, some marking this (e.g. colouring the values read), some not. 20 of 50 blood glucose monitoring apps allow the meaningless reading of 111 mmol/L, and 24 of 46 apps that monitor pulse allow a value of 333 bpm (s. Figs. 5 and6). Some of the apps even allowed to input letters instead of numerical values. This raises serious safety concerns. Lacking input validation stands for poor code quality and is a precondition for attacks like SQL injection, XSS, and XSRF.

The majority of apps do not protect the medical data when stored in the internal storage. An attacker gaining physical access to the device can thereby access or manipulate these data. This attack can be impeded but not entirely prevented by using the phone's security mechanisms like PIN protection and device encryption. In contrast to [START_REF] He | Security threats to Android apps[END_REF][START_REF] He | Security concerns in Android mHealth apps[END_REF] we did not find any sensitive data in Android's main and event log. Only 4 apps allowed to protect the app with an extra password. 49 of 72 apps export medical data to SD card. All but one of these do not protect the data when doing so. The one exception is MyLists, which is not a specific health app. Thus, an attacker with physical access to the device can steal the SD card and gain thereby access to the medical data. This finding is surprising as some of the developer tools included in the apps like PDFTron would allow encryption. This also indicates dead code in the APKs. Only 32% of the apps provide a "wipe" feature to delete all medical data entered. Unfortunately, the SD card is often omitted from this wipe. 68% of the apps allowed to send e-mails. None of these allowed for sending encrypted messages or attachments. This could allow attackers with access to the network infrastructure (e.g. in WLANs) to sniff or even manipulate e-mails in transit. Besides export to 20 different web servers, we successfully exported data to Facebook (2 apps), Twitter (2), Google Drive (6), and Dropbox (8) without receiving a privacy warning by the app.

Several ad networks transmit the app's package name plus other device and app specific data in clear text which allows a passive eavesdropper to gather the information which device is using which app. This can often traced back to individual users thereby laying open that a user has diabetes or is tracking their blood pressure. We found this among others in HTTP traffic related to doubleclick.net, googleapis.com, gstatic.com, applovin.com. Similar findings (albeit not for mHealth) have been reported in [START_REF] Vallina-Rodriguez | Breaking for commercials: characterizing mobile advertising[END_REF].

Web applications. 35% of all analysed apps transmit medical data in textual or other forms (like pictures, charts, files) in clear text using HTTP. This is not limited to blood pressure or glucose values but also includes weight, BMI, and pulse (Fig. 7). The same percentage of passwords can be sniffed in cleartext. The password policies also leave much to be desired. One app allows empty passwords, 5 are fine with one character passwords, and only 3 ask for or generate passwords of 8 characters or more. Additionally, 17 of 20 apps accept password consisting just of numbers in a chronological order which allows easy brute force and dictionary attacks. Privacy policy. Only 19% of all 154 refer to a privacy policy in the app stores, but this number increases to 67% for apps which allow users to sync data with web servers. On average, the policies are 632 words long. Only 6 policies stem from 2014, the others being older, 4 give no date. mHealth is a global business with a trend towards USA and Germany. While the majority of the policies cover the OECD privacy principles of accountability, security safeguards, openness, and purpose at least partly, over half of the policies do not address the rights of the individual like the right of data deletion. None of the policies denies using the data internally e.g., for marketing or research. 9 policies explicitly say that they do so. All policies addressing mergers note that medical data may be transferred or even sold. 50% of the apps (that address this issue) say that medical data can be passed on to other 3rd parties (other than required by law).

× --------- com.diabetesstudio.client 500 × × × × × × × × × -× - com.fourtechnologies.myne 100000 × × × × × × × × × × × com.freshware.dbees...... 50000 × × × × × --× com.glooko.logbook....... 5000 × × × × × × -× × com.kiwihealthcare.glubud 5000 × × × × --------- com.leadingedgeapps.ibp.. 5000 × × × × × × × × × --- com.mysugr.android.compan 50000 × × × × × × -- com.nabdacare.diabetes... 1000 × --------- com.oxygenhealthcom.lsmea 1000 × × × × × × × × --× × com.sidiary.app....... 50000 × ---× com.socialdiabetes.androi 10000 × × × × × × × × × × -- com.squaremed.diabetescon 50000 × × × × × × × -- com.squaremed.diabetesplu 50000 × --------- de.davidfroehlich.diabete 500 × × ---- it.

Conclusions

Through our in-depth analysis, we found clear evidence of privacy, safety, and security concerns for the majority of the apps we analysed. Current health policy strongly encourages people to manage chronic conditions themselves, and mHealth is seen as a key tool for effective self management. But the apps people use should not leave them vulnerable to cyberattacks. While the consequences of such attacks may be relatively mild for the conditions we studied, hypertension and diabetes, they may be more severe for stigmatised conditions such as HIV+ or mental illness. Some of the issues, such as the pervasive lack of encryption, indicate security is not a priority for developers. Reports, charts, and tables of medical data are often stored without any protection, giving thieves and eavesdroppers easy access. Another important threat is advertising. Of the 154 apps tested, 74 include advertisement addons. These addons often transmit the app's package name in clear text in the HTTP header which discloses the usage of this app (which is, per se, sensitive) to eavesdroppers. We also pointed out that current malware and privacy scanners fail to identify privacy issues in mHealth apps.

On the user interface side, we found that input data was often not validated or badly validated. This is a major concern when users want to share their self-curated data with health care professionals. The problems that arise from badly validated and designed data input forms have been studied extensively, and design guidelines have been formulated, but many app developers (and many medical device manufacturers) still fail to adhere to them [START_REF] Thimbleby | Improving safety in medical devices and systems[END_REF].

App developers also rarely provide privacy policies. Although most users are unlikely to read such policies [START_REF] Nissenbaum | A Contextual Approach to Privacy Online[END_REF], we would still expect that privacy policies offer a reasonably complete summary of all major privacy issues for people who do read them. Most of the policies we analysed fell far short of this goal. Quote6 : "Sinovo endeavours to use on the data minimally. The customer expressly agrees to the use of data in this context."

Recommendations. Due to the manifold concerns over the privacy and security of health data that users enter into mHealth apps in good faith, we suggest that app shops should mandate and enforce the existence of a privacy policy for apps that would like to be listed in the Health section. They could provide a template which systematically addresses the major principles and encourage automated security checking of apps with tools like MalloDroid or Drozer. Such a step would automatically encourage developers to invest time and effort in ensuring users' privacy. Secure coding guidelines like [START_REF]CERT secure coding standards for Android[END_REF] are a good start. Developers should leverage existing tools to encrypt all data stored both on the device and on external servers. Finally, developers should also ensure that the privacy policy is up to date, follows the OECD principles, and informs end users about use of their data and data protection.

Ad Networks, an important revenue source for free medical apps, are also a major source of privacy leaks. Here, many concerns could be addressed by mandating the usage of SSL to protect the HTTP traffic.

Looking at the Android operating system, the INTERNET permission seems too coarse. Currently it is not possible to differentiate whether a mHealth app wants to communicate with a health care provider or if an ad server is contacted. A possible solution could be the inclusion of firewall features in future Android versions, but this might conflict with Google's ad driven business model.

The recommendation to end users is to perform due diligence, including reading the description, privacy policy, and commenting on security issues, trying to take advantage of scores for privacy measures such as ours and those given by others [START_REF] Adhikari | Security and privacy issues related to the use of mobile health apps[END_REF][START_REF] Michael | Technical analysis of the data practices and privacy risks of 43 popular mobile health and fitness applications[END_REF]. But the information currently available prior to installation is not enough for users to make these informed decisions. Therefore, a privacy aware user needs to use additional mechanisms like Android's phone encryption, ad block apps, or encryption apps. This is only feasible for technically savvy users.

Related work. Work closest to our contribution stems from [START_REF] Adhikari | Security and privacy issues related to the use of mobile health apps[END_REF][START_REF] Michael | Technical analysis of the data practices and privacy risks of 43 popular mobile health and fitness applications[END_REF][START_REF] He | Security threats to Android apps[END_REF][START_REF] He | Security concerns in Android mHealth apps[END_REF]. Njie [START_REF] Michael | Technical analysis of the data practices and privacy risks of 43 popular mobile health and fitness applications[END_REF] analyses 43 popular iOS and Android health and fitness apps based on a spreadsheet with the focus on network analysis and mentions the need to restrict future studies to a more specific category of apps. He et al. [START_REF] He | Security concerns in Android mHealth apps[END_REF][START_REF] He | Security threats to Android apps[END_REF] analyse 47 randomly selected iOS and Android mHealth apps in a series of two studies regarding Internet usage, logging, content provider, SD cards, and usage of cloud services and Bluetooth. Adhikari et al. [START_REF] Adhikari | Security and privacy issues related to the use of mobile health apps[END_REF] examine the 40 most popular iOS and Android mHealth apps by answering 9 privacy questions yielding a privacy score.

In contrast these studies, our work focuses (1) on apps for specific purposes, rather than selecting randomly from the broad category of mHealth apps and (2) only on Android apps. This gives us a more homogeneous population which can be closely tested and compared, in particular, it allowed us to check input validation for specific blood pressure and glucose reading ranges. Our testing also goes further than previous work: while permissions and network traffic have been considered, we additionally analyse the APKs and the underlying code and privacy policies, and source code quality.

Future work. Our methodology is sensitive enough to uncover many privacy and security concerns, and it can be easily extended to apps for conditions that are more stigmatised than diabetes and hypertension, such as mental health [START_REF] Roeloffs | Stigma and depression among primary care patients[END_REF].

We propose to extend our technical work in three ways. First, we want to extend static analysis to more of the 27 topics in [START_REF]CERT secure coding standards for Android[END_REF], integrating formal usability assessment, and developing automatic tools that might be used to screen new candidate apps for mHealth. Given the prevalence of web servers associated with apps, assessing web application security is an integral part of a full analysis; we'd like to extend this to consider vulnerability to attacks like SQL injection, XSS, and XSRF. Finally, apps that use communication links like Bluetooth and NFC to regulated measurement devices deserve to be examined in detail too, especially in a "wearable scenario".

In order to link our results to the eHealth field, we plan to investigate the motivations of users of mHealth apps and their attitude to the safety, security, and privacy problems we found. We also plan to investigate reasons why developers create insecure apps through a questionnaire study.

Fig. 1 . 2 .

 12 Fig. 1. Input in iBP Blood Pressure Fig. 2. Functions of Diabetes Journal

Fig. 3 .

 3 Fig. 3. An mHealth app in context. The heart indicates medical data.

Fig. 4 .

 4 Fig. 4. Analysis method

Package D o w n l o a d s T y p e l a c k s p r i p o

Fig. 5 .

 5 Fig. 5. BloodPressure Record Lite allows to enter lethal blood pressure values Fig. 6. Diabetes Journal (Suderman) allows to enter lethal blood sugar values

Table 2 .c o u n t a b i l i t y s a f e g u a r d s o p e n n e s s p u r p o s e s p e c i fi e d i n d i v i d u a l p a r t i c i p a t i o

 2 Results of the privacy policy and web security analysis

  Fig. 7. Clear text blood pressure reading (com.oxygenhealthcom.lsmeasure)

	bytewave.glucowave....	500 × × × ×	× ×		× ---
	net.klier.blutdruck......	100000	×	× ×	×	-	-
	org.fruct.yar.bloodpressu	100000	×	---------

Hypertension affects 25%-55% of the population depending on the country and the definition, while diabetes affects 8.5% of Europeans.

The full details of the apps analysed, along with a database of our results and details about the tools used can be found at the URL http://tinyurl.com/mhealthapps. A more comprehensive description of the method can be found in[START_REF] Knorr | Security Testing for Android mHealth Apps[END_REF].

We did not find any suspicious network traffic caused by these two apps during the dynamic analysis

http://www.sinovo.org/?id=144