MockDroid: trading privacy for application functionality on smartphones Alastair R. Beresford Andrew Rice Nicholas Skehin Computer Laboratory, Computer Laboratory, Computer Laboratory, University of Cambridge, University of Cambridge, University of Cambridge, 15 JJ Thomson Avenue, 15 JJ Thomson Avenue, 15 JJ Thomson Avenue, Cambridge. CB3 0FD Cambridge. CB3 0FD Cambridge. CB3 0FD United Kingdom United Kingdom United Kingdom [email protected] [email protected] [email protected] Ripduman Sohan Computer Laboratory, University of Cambridge, 15 JJ Thomson Avenue, Cambridge. CB3 0FD United Kingdom [email protected] ABSTRACT 1. INTRODUCTION MockDroid is a modified version of the Android operating In the last couple of years, third-party applications for system which allows a user to `mock' an application's ac- smartphones have become very popular for users and devel- cess to a resource. This resource is subsequently reported opers alike. For example, Apple has nearly 250,000 appli- as empty or unavailable whenever the application requests cations in its store [3] and has served over 3 billion down- access. This approach allows users to revoke access to par- loads [1]. This is due to the confluence of several technical, ticular resources at run-time, encouraging users to consider business and economic factors, including the availability of the trade-off between functionality and the disclosure of per- good mobile data connectivity, high-performance low-power sonal information whilst they use an application. Existing hardware, an online application store, and an integrated applications continue to work on MockDroid, possibly with billing system which allows application developers to col- reduced functionality, since existing applications are already lect payment for applications easily. Many modern mobile written to tolerate resource failure, such as network unavail- phone vendors have applications stores, including the App ability or lack of a GPS signal. We demonstrate the prac- Store (Apple), App World (Blackberry), Android Market ticality of our approach by successfully running a random (Google), Windows Marketplace for Mobile (Microsoft) and sample of twenty-three popular applications from the An- the Ovi Store (Nokia). droid Market. All the major platforms provide programming APIs which allow access to many of the core services of the smartphone, Categories and Subject Descriptors including: communication capabilities (e.g. IP connections, phone calling and text messaging), databases of personal in- D.4.6 [Security and Protection]: Access Controls; J.7 formation (e.g. address book and calendar data), and sensor [Computers in Other Systems]: Consumer products; information (e.g. microphones, cameras, phone location, and H.4 [Information Systems Applications]: Miscellaneous accelerometer data). Unfettered access to these data sources is a real privacy concern for users. General Terms Smartphone operating system vendors are aware of the potential for poorly written or malicious programs to com- Mobile, Phone, Security, Privacy promise privacy. Several different approaches have been de- veloped to reduce the risk. Application vetting is a popu- Keywords lar technique, used for a long time by Symbian, and now Android, MockDroid adopted by Nokia and Apple. In this model, the developer writes and tests an application on a specific device. Once the application is complete, the developer submits the ap- plication to a trusted party for testing; this might be the Permission to make digital or hard copies of all or part of this work for operating system vendor themselves or a third party. Typi- personal or classroom use is granted without fee provided that copies are cally, testing checks for adherence to published design guide- not made or distributed for profit or commercial advantage and that copies lines in addition to checking for malicious behaviour. If the bear this notice and the full citation on the first page. To copy otherwise, to trusted party approves the application, it digitally signs the republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. application; phone handsets will not install an application HotMobile ’11 Mar 01-03 2011, Phoenix, AZ, USA unless it is signed by a trusted key. Copyright 2011 ACM 978-1-4503-0649-2/11/03 ...$10.00. The vetting process is often opaque and suffers from both tual state of the GPS device, prevents the application from false accepts and false rejects. As the largest store, appli- providing search results based on accurate location data, or cations written for the iPhone provide several high-profile showing the current location of the user on the map; other examples, although other application stores also suffer from features of the application, such as directions, continue to similar problems. Once recent example is the latest version function as normal. Therefore, providing fake data allows of the Facebook application for Apple's App Store. The the user to explore the trade-off between functionality and Facebook application uploads all the contacts in the user's privacy for any given application. Lying in this way offers a phone address book and then pattern matches these entries number of advantages over simple mandatory access control: with the user's friends on Facebook. Newspaper reporters Controlling optional features It is common for applica- have discovered these numbers are not just stored on Face- tions to request access to a specific API to provide a book; they are also associated with the profiles of matching feature which is optional; for example, the Skype appli- friends, and therefore a phone number which is only avail- cation on Android allows the user to choose whether to able to a small number of people is shared more widely [4]. integrate Skype contacts with the main phone address In the first release of the application users were not made book. This kind of feature selection can be enforced by aware of this new feature and it cannot be disabled easily in the operating system rather than by the application. the phone application. A popular alternative approach to vetting is to use manda- No unwarranted sharing of personal data Many appli- tory access control. This technique is used by Android and cations which access personal data upload it to remote also the J2ME platform, which are both available on many servers without the user realising. For example, a re- different mobile device handsets. In this model, the devel- cent analysis of thirty Android applications which re- oper declares which APIs the application will use and the quested Internet connectivity along with location data system runtime prevents the application from accessing any or device ID found that twenty shared location data APIs it does not explicitly list. The set of permissions re- with content servers or third-party advertising net- quested by the application can be reviewed by the user. On works without seeking user consent [6]. Allowing ac- the Android platform, the permissions are displayed when cess to be mocked puts the user back in control. the application is installed, and the user has to make a stark Data separation For some data sources, it might be use- choice: grant the permissions and install the application, or ful to provide a subset of the data, such as providing don't use the application at all. The J2ME model is slightly only public calendar events to a specific application. more flexible: some platforms allow the user to select op- Similarly, it may be useful to control the quality of the tions such as \always", or \ask every time" for some APIs, data provided; for example, rather than providing the although applications may fail to run correctly if access is precise location of the phone to an application which denied. Some J2ME platforms only allow access to certain shares such data with friends, the user might provide APIs if the application has been vetted and signed, building the location of the nearest city. Users could even main- a hybrid combination of the vetting and mandatory access tain a separate database of personal information for control models. each application if they wish. The problem with the the mandatory access control model is the user must give permission to access communication Controlling expensive operations Access to some APIs features or data without necessarily being able to under- cost money, and therefore lying helps control costs. stand when and why this access is required, or what hap- For example, if the 3G data connection costs money, pens with their data. On Android this is especially difficult lying allows a user to prevent a data-hungry applica- since there is no \ask every time" option; after installation, tion from using the network whilst other applications applications can access any requested API without further continue to work as normal. user intervention. Enabling new features Many applications make use of In this paper we propose an alternative approach: allow sensor readings or information from personal databases the user to provide fake or `mock' data to applications in- to control the user experience. By allowing users to teractively as the application is being used. In other words, mock certain information, new features are automat- the user may provide different information on the status of ically enabled. For example, accelerometers are often communication capabilities, personal databases and sensors used to control the orientation of the screen. By pro- to each application and over time. For example, consider an viding fake accelerometer data to a specific application application which requests IP connectivity, access to loca- the user can manually rotate the application screen in- tion data from the GPS sensor, and read-write access to the dependently of the actual phone orientation. calendar database. On MockDroid, the user may choose to provide `mock' GPS data, such as always reporting a spe- Testing Developers can use mock resources to test their cific latitude and longitude, or reporting \no location fix applications to make sure they work correctly with the available" regardless of the actual status of the GPS device.