A Study on How to Improve Android
Permissions to the IoT Context

Abstract

Today, smartphones are sources of a great amount of personal information, e.g., the owner's contacts, photos, text messages, and current location. To prevent Android applications from freely obtaining such sensitive information, the system relies on permissions, a security mechanism which requires users to explicitly consent to an app's access to possibly harmful data. In this work, we describe the functioning of Android's permission system and its flaws, specially in an Internet of things (IoT) environment, and study ways to solve them.

Keywords: Android, Permissions, Privacy, Internet of things.

Blog

Index:

1. Definitions
2. What Are Permissions
3. Types of Permissions
1. Normal Permissions
2. Dangerous Permissions
4. Android 6.0
5. Permission Groups
6. Requesting Permissions
7. Defining Permissions
8. Context
9. Shopping List App
10. Shop App and IoT

Index

Definitions

Here are some definitions of words we are going to use in the future (more definitions will be added as we use them):

• Application Programming Interface (API):  A set of commands a program offer in order for other programs to communicate with it and use its functionalities; it works as a courier that takes a request from program A (which is using the API) to program B (which the API belongs to), tells B what to do, and returns the response from B to A. For example, if my app wants to access the information of a person on Facebook, the Facebook API allows me to request this information to the database and receive it without having direct access.

---

• Package:  The set of files behind an application or middleware.
• App Manifest:  "Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest file provides essential information about your app to the Android system, which the system must have before it can run any of the app's code." [1].
• API Level:  An integer that identifies a revision of the Android API (simply put, it's the API's version number).
• Target SDK:  An integer value set in the app manifest which indicates the API Level the application is designed to run in.
• Activity:  One of the essential components of an app. Each activity represents (in the form of code) a single screen of the application, and together they form its visual representation. Inside an activity, it is defined, for example, how the screen is layed out, how it behaves when you access it, and what happens when you interact with it.
• Intent:  A message passed between the app's components or even between apps, relaying the intention of the application to do something or the need of something to be done for it. These messages can have specific targets or can be broadcasted (to be received by the components or applications that can handle the intent). For example, an app can broadcast the ACTION_IMAGE_CAPTURE intent which tells any receiving application that it needs a photo to be taken. The Android system can also broadcast intents to indicate events such as the battery being charged or the system booting up.

  ---

• Internet of Things (IoT):  "The interconnection via the Internet of computing devices embedded in everyday objects, enabling them to send and receive data" [2].
• Multi-sided Platform (MSP):  Also known as two-sided platform or two-sided market, it's a model where "[...] businesses serve distinct groups of customers who need each other in some way, and the core business of the two-sided platform is to provide a common (real or virtual) meeting place and to facilitate interactions between members of the two distinct customer groups." [3] Some examples of MSPs are eBay, Facebook, PayPal and Uber.
• Sensor Data:  The information outputted by sensors (devices that respond to inputs from the physical environment). For example, temperature readings are the sensor data outputted by a thermometer, which is a sensor.
• Actuator Access:  The right to utilize an actuator, which is a mechanism controlled by a system that acts upon an environment. For example, a digital door lock involves the lock itself (the actuator) and the software behind it (the control system); if the door's owner give actuator access to someone else, that person can lock and unlock the door while he/she has the access.
• Data Analytics:  The process of examining and refining collected data in order to draw conclusions about it or to support decision-making. Meteorological forecasts are an example of data analytics based on weather reports.

Note: We will sometimes refer to sensor data, actuator access, and data analytics collectively as 'IoT services', because for this study they will always be related to the Internet: Sensor data will be collected by or stored in devices connected to the Internet, actuator access will allow the remote control via the Internet of the actuator (because its control system supports it), and data analytics will be based on information collected through the Internet or be offered online to parties interested in its results.

Footnote:
1. https://developer.android.com/guide/topics/manifest/manifest-intro.html
2. https://en.oxforddictionaries.com/definition/internet_of_things.
3. David S. Evans, Platform Economics: Essays on Multi-Sided Businesses (2011, p.2).

Index

What Are Permissions

Android has a built-in security feature called the Android Application Sandbox, which isolates apps from each other and from the system itself, giving them a space with restricted access called process sandbox, where they can operate safely.

Permissions, as the name implies, are authorizations given to an app that allow it to access resources and data outside of it's own sandbox. These authorizations are, sometimes, required for an application to function properly and will render it useless if it doesn't have them. For example, having a photo editor app is pointless if it can't access your device's images or camera.

Index

Types of Permission

• Normal Permissions: They involve the access to features and information that offer very little to no risk to the user's privacy or to the execution of other apps, such as a phone's vibrator. These permissions are automatically granted to an app when it needs them.
• Dangerous Permissions: They involve the access to features and information that may harm the user's privacy, affect the device's stored data or interfere with the execution of other apps. For example, access to a user's contact list or location. When an app needs dangerous permissions, the user has to give them to it explicitly.

Index

Normal Permissions

• ACCESS_LOCATION_EXTRA_COMMANDS: Lets the application send additional commands to the location provider, which allow it to delete all or part of the stored GPS data, for example.
• ACCESS_NETWORK_STATE: Lets the application access the device's network information, such as whether it is connected to a network at all and what kind of network it is. It's mainly used to allow the monitoring of network connections.
• ACCESS_NOTIFICATION_POLICY: Lets the application access the notification policy, which manages the user's preference for how the notifications are filtered (which ones are shown, for example).
• ACCESS_WIFI_STATE: Lets the application access information about, specifically, Wi-Fi networks.
• BLUETOOTH: Lets the applications connect to paired bluetooth devices.
• BLUETOOTH_ADMIN: Lets the applications discover and pair bluetooth devices on it's own.
• BROADCAST_STICKY: Lets the application broadcast sticky intents, which are intents that stay around even after the broadcast is complete so that future broadcast listeners might receive them. For example, if the device's battery is low, the system broadcasts the ACTION_BATTERY_LOW intent, which stays around if any app wants to receive it.
• CHANGE_NETWORK_STATE: Lets the application change the device's network connectivity state.
• CHANGE_WIFI_MULTICAST_STATE: Lets the application enter Wi-Fi Multicast mode, which allows the device to receive packets addressed to multicast addresses.

Multicast Adressing: Normally, packets (simply put, data) is sent in a network from one device to another. Multicast allows a device to send packets to group of devices by sending them to a multicast address (a group's address), instead of a single device's address.

• CHANGE_WIFI_STATE: Lets the applications change the Wi-Fi's connectivity state
• DISABLE_KEYGUARD: Lets the application disable the keyguard (the device's lockscreen).
• EXPAND_STATUS_BAR: Lets the application expand or collapse the status bar.
• GET_PACKAGE_SIZE: Lets the application know the space used by any package.
• INSTALL_SHORTCUT: Lets the application install a shortcut on the device's home screen.
• INTERNET: Lets the application use the internet.
• KILL_BACKGROUND_PROCESSES: Let the application call a method that kill processes in the background, primarily to free memory.
• MODIFY_AUDIO_SETTINGS: Lets the application change the device's global audio settings.
• NFC: Lets applications to perform input/output (I/O) operations over near field communication (NFC).
• READ_SYNC_SETTINGS: Lets application read the sync settings, which manages what information from which services are synchronized to their respective servers, in case you want to use it on another device, for example.
• READ_SYNC_STATS: Lets application read the sync stats, which contain various information such as how many deletes and updates were made by a sync operation.
• RECEIVE_BOOT_COMPLETED: Lets the application receive the ACTION_BOOT_COMPLETED intent that is broadcast after the system finishes booting.
• REORDER_TASKS: Lets the application change the order of tasks
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS: Lets the application use the ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent, which requests the user to allow the app to ignore battery optimizations, such as the ones made when the device is in power saving mode.
• REQUEST_INSTALL_PACKAGES: Lets the application request installing packages. It is necessary for launching the app's installer.
• SET_ALARM: Lets the application broadcast an Intent to set an alarm for the user.
• SET_TIME_ZONE: Lets the application set the system time zone.
• SET_WALLPAPER: Lets the application set the device's wallpaper.
• SET_WALLPAPER_HINTS: Lets the application set the system wallpaper size hints which indicates which portion of an image will fit into the wallpaper.
• TRANSMIT_IR: Lets the application use the device's infrared (IR) transmitter, if it has one.
• UNINSTALL_SHORTCUT: Lets the application delete a shortcut from the device's home screen. (this permission was removed)
• USE_FINGERPRINT: Lets the application use the device's fingerprint hardware (such as a fingerprint reader), if it has any.
• VIBRATE: Lets the application access to the device's vibrator.
• WAKE_LOCK: Lets the application use PowerManager WakeLocks (which is a mechanism an app uses to indicate it needs the device to stay on) to keep the CPU from sleeping or the screen from dimming.
• WRITE_SYNC_SETTINGS: Lets the application write the sync settings.

(source: https://developer.android.com/guide/topics/permissions/normal-permissions.html)

Index

Dangerous Permissions

• READ_CALENDAR: Lets the application read the user's calendar data.
• WRITE_CALENDAR: Lets the application to write the user's calendar data. In other words, it allows the app to create new entries, change existing ones and delete them.
• CAMERA: Grants access to the device's camera.
• READ_CONTACTS: Lets the application read the user's contacts data.
• WRITE_CONTACTS: Lets the application write the user's contacts data. In other words, it allows the app to create new contacts, change existing ones and delete them.
• GET_ACCOUNTS: Lets the application access the list of accounts in the device's Account Service. In other words, it allows the application see what accounts the user is logged in to (such as Facebook and Google accounts).
• ACCESS_FINE_LOCATION: Lets the application know the precise location of the device.
• ACCESS_COARSE_LOCATION: Lets the application know the approximate location of the device.
• RECORD_AUDIO: Lets the application record audio by using the device's microphone.
• READ_PHONE_STATE: Lets the application read (and only read) data about the phone state, which include the device's phone number, current cellular network information, the status of any ongoing calls, and a list of all different methods of making and receiving calls, besides the standard SIM-based phone call, registered on the device.
• CALL_PHONE: Lets the application make a phone call without using the dialing interface or needing the user to confirm the call.
• READ_CALL_LOGS: Lets the application read the user's call log data.
• WRITE_CALL_LOGS: Lets the application write, but not read, the user's call log data. In other it allows the app to create new call logs.
• ADD_VOICEMAIL: Lets the application add voicemails into the system.
• USE_SIP: Lets the application use the Session Initiation Protocol (SIP) service, which, simply put, allows the app to setup, manage and terminate sessions, such as voice calls and video conferences, in an IP based network.
• PROCESS_OUTGOING_CALLS: Lets the application see the number being dialed during an outgoing call with the option to redirect the call to a different number or to abort it.
• BODY_SENSORS: Grants access to data from sensors that the user uses to track what is happening inside his/her body, such as heart rate and blood pressure.
• SEND_SMS: Lets the application send SMS messages.
• RECEIVE_SMS: Lets the application receive SMS messages.
• READ_SMS: Lets the application read SMS messages.
• RECEIVE_WAP_PUSH: let's the application receive WAP push messages.
• RECEIVE_MMS: Lets the application monitor incoming MMS messages.

SMS, WAP and MMS: The difference between these types of messages is that SMS messages are meant for short messages, WAP messages contain a link to a web page attached to their contents ( looking and working similar to this text that has a link to Facebook embed to it), and MMS messages support bigger texts and allow you to attach media files, like songs and videos, to them.

• READ_EXTERNAL_STORAGE: Lets an application read from external storage.
• WRITE_EXTERNAL_STORAGE: Lets an application write to external storage.

(source: https://developer.android.com/guide/topics/permissions/requesting.html#)

Index

Android 6.0

Before the release of Android 6.0 Marshmellow, an application would request all the dangerous permissions it needed during the installation process and the user had to accept all of them if he/she wanted to install the app on their devices. Furthermore, the only way of revoking any of these permissions, without the use third-party applications, was to uninstall the application.

With its release, up-to-date applications are now required to request each permission individually during runtime, and the user can manage each app's permissions on the device's settings (being able to disable any of them at any time).

The probable motivation behind this new approach, besides speeding up the installation process, is the increase of user security. Studies made before the release of 6.0 show that an alarmingly low percentage of Android users pay attention to permissions when installing an app, and that an even lower number understand what each permission entitles the application to do; they conclude Android permissions fail to inform the user of the privacy and security risks permissions impose if used improperly [4, 5].

By sending permission request individually to the users, even if unintentionally, Android forces them to pay closer attention to permissions by giving more emphasis to each one of them . And, by allowing users to disable permissions, it gives them the ability to deny the application of any permission that they deem harmful or don't understand properly.

Footnote:
4. Patrick Gage Kelley, Sunny Consolvo, Lorrie Faith Cranor, Jaeyeon Jung, Norman Sadeh, and David Wetherall, A conundrum of permissions: installing applications on an android smartphone, International Conference on Financial Cryptography and Data Security, Springer, 2012, pp. 68–79.
5. Adrienne Porter Felt, Elizabeth Ha, Serge Egelman, Ariel Haney, Erika Chin, and David Wagner, Android permissions: User attention, comprehension, and behavior, Proceedings of the eighth symposium on usable privacy and security, ACM, 2012, p. 3.

Index

Permission Groups

Dangerous permissions in Android all belong to permission groups. For example, the READ_CALENDAR and WRITE_CALENDAR permissions, that allow an application to, respectively, read and write the user's calendar data, both belong to the CALENDAR permission group.

When an application needs a dangerous permission, the system always requests its permission group, never it individually (no matter the Android version). If he/she accepts the request, all the permissions within that same group will be automatically granted, without notifying the user, if the app requests them.

When managing the permissions of an application in Android 6.0 or higher, the user also works with permission groups and cannot enable or disable each dangerous permission individually.

Dangerous permissions and their current permission groups.

(source: https://developer.android.com/guide/topics/permissions/requesting.html)

Index

Requesting Permissions

Declaring Permissions

Before requesting any permission, it is necessary to declare all the permissions the application is going to use in its app manifest, by listing each one as a <uses-permission> element under the <manifest> element.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myappname">

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.CAMERA" />

    <application ...>
        ...
    </application>

</manifest>

An app declaring it's going to use the INTERNET and CAMERA permissions.

All normal permissions declared in the manifest will be automatically given to the app, without the user ever being notified about them.

If the device is running Android 5.1 or lower, or if the application's target SDK is 22 or lower, all of the declared dangerous permissions' groups will be granted if the user agrees to install it, and no further steps are necessary. Else, if the device is running Android 6.0 or higher, and if the application's target SDK is 23 or higher, the app must also request each dangerous permission declared in the manifest while it's running.

Checking For Permissions

Since devices running Android 6.0 (API Level 23) allow users to change an application's permissions in its settings, it is a good practice to always check if the app has a dangerous permission before using it's related features and information (regardless of the app's target SDK). To do this, the method ContextCompat.checkSelfPermission() is used, which takes as arguments an activity (usually the activity where the permission will be used, which in most cases is the same activitity calling the method) and the permission to be checked. It returns:

• PackageManager.PERMISSION_GRANTED if the application has the permission;
• PackageManager.PERMISSION_DENIED if it doesn't, requiring the app to explicitly request it to the user.

if (ContextCompat.checkSelfPermission(this,
    Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED) {          
    ...
 } 
else { /* ContextCompat.checkSelfPermission(this,
          Manifest.permission.INTERNET) == PackageManager.PERMISSION_DENIED */
    ...
}

A piece of code that checks if the application has theCAMERA permission ("this" is the activity in which the code is located).

Requesting Permissions

To request one or multiple permissions to the user, the method ActivityCompat.requestPermission() is used, which takes as arguments the activity that will use the permission(s) (usually the same activity calling the method), an array containing all the permissions to be requested by the method call, and a request code, which is a integer that uniquely identifies the call.

ActivityCompat.requestPermissions(this,
        new String[]{Manifest.permission.CAMERA}, 1234);

A call which requests the CAMERA permission to the user, attaching the request to the code 1234.

With the method call, each dangerous permission that doesn't belong to a permission group already owned by the application will be requested via a prompt to the user which, again, requests the permission group and not the permission itself.

If the user denies requests for a permission group multiple times, he/she can opt to not be asked for it again, which will make the system automatically deny any future request made for it.

Handling the User's Response

After the user replies to all requests made by an ActivityCompat.requestPermission() call, the system calls the application's onRequestPermissionsResult() method, passing as arguments the request code of all the requests, the array with all the permissions requested, and an array containing the user's reponse for the permissions listed in the previous array. The application must handle all responses (considering the possibility of multiple request codes), either by performing the operations related to the permissions (if their request was accepted) or by disabling them (if it was denied).

@Override
public void onRequestPermissionsResult(int requestCode, 
	    String[] permissions, int[] grantResults) {

    /* If the user cancels the requests 
       the results array stays empty. */
    if (grantResults.length > 0) 
       
        switch(requestCode) {
            case 1234:
                if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                    // Perform the operations related to the permission.
                }
                else { // grantResults[0] == PackageManager.PERMISSION_DENIED
                    // Disable the operations related to the permission.
                }
                break;
        }
}

The implementation of the onRequestPermissionsResult() method which the system will call after the user replies to request sent by the ActivityCompat.requestPermission() call from the previous example.

(source: https://developer.android.com/training/permissions/requesting.html)

Index

Defining Permissions

Declaring the Permission

The first step when defining custom permissions in Android is to declare them in the app manifest, describing each one inside a <permission> element, all children of the <manifest> element.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp" >

    <permission android:name="com.example.myapp.permission.MY_PERMISSION"
        android:label="@string/permlab_myPermission"
        android:description="@string/permdesc_myPermission"
        android:permissionGroup="android.permission-group.PHONE"
        android:protectionLevel="dangerous" />

    ...

</manifest>

An example of custom permission declaration.

As the example above demostrates, some attributes need to be set on a permission's declaration:

• name: The permission's name. Different packages cannot declare permissions with the same name.
• label: A string containing a short text of information about the permission. Labels are shown, for example, on the list of permissions displayed when installing an app on a device running Android 5.1 or lower.
• description: A string containing more detailed information about the permission. Descriptions are shown, for example, when the user select one of the permissions listed when installing an app on a device running Android 5.1 or lower.
• permissionGroup: (optional) The permission group which the permission belongs to. It can be an existing group or a custom one.
• protectionLevel: The system's behavior when the permission is requested. The possible values for this attribute are:
  • normal: The protection level for a normal permission. The declared permission is automatically granted to any requesting app when it is installed.
  • dangerous: The protection level for a dangerous permission. The declared permission must be granted directly by the user when it is requested.
  • signature: All Android applications must be signed with a certificate by their developers. A signature permission is only granted if the requesting app is signed with the same certificate as the app which declares the permission. If this condition is met, it is automatically granted without notifying the user.
  • signatureOrSystem: The system only grants this permission to applications signed with the same certificate as the app which declares it or to applications pre-installed to the device's system, such as Google Maps for most Android devices.

Enforcing the Permission

After the permission is declared, it needs to be enforced inside the application. This can be accomplished mainly in two places:

The first one is the app manifest, where broad components of the app can be enforced with the defined permission by adding an android:permission attribute to them. For example, by restricting an activity, the developer limits which entities can start it (in other words, who can make the screen associated with it be displayed on the device's screen).

The second one is the application's code itself, with methods such as Context.checkCallingPermission() and Context.checkPermission() (that check if a process has a permisison) and PackageManager.checkPermission() (that checks if a package has a permission) which can be used to enforce the defined permission in small parts of the code.

(source: https://developer.android.com/guide/topics/permissions/defining.html)

Index

Context

Privacy is among the most discussed subjects of modern society. When referring to it, people tend to use Samuel Warren and Louis Brandeis' definition as the "right to be let alone"; a necessity born from the advent of intrusive journalism, which sensitized the population to publicity and lowered social standards and morality [6]. Although not all may fully agree with such a definition, none question privacy is indeed a necessity, an increasing one at that. Practices like the creation of invasive laws (e.g., the Investigatory Powers Act, which grants UK's secret service the right to carry out heavy surveillance) and the development of powerful monitoring technology help create an environment where exposure, and even the fear of it, inhibits the population and hinders their autonomy.

When faced with this reality, people may react in very different ways. Some may confront it and fight for the right to privacy (an extreme example being Edward Snowden, whose leaks on the extensive internet and phone surveillance done by the US National Security Agency sparkled global outrage in 2013); while others may accept it, becoming complacent to these practices, or reject it, alienating themselves from society. There is a large variety of behaviors an individual can assume in such a scenario, it isn't a situation where someone is simply "for it" or "against it".

Such a wide spectrum of perspectives on privacy stems from an equally large diversity of contexts. For example, culturally, the Mehinaku Indians of central Brazil are raised with minimal privacy: their communal houses have no internal walls and are arranged around an open central area with clear visibility; in addition, villagers can easily identify each other's footprints, and thus determine a fellow tribesmen's whereabouts [7]. In other words, the Mehinaku always assume their actions to be known by their peers, it's part of their tradition, their norm, to not have privacy. Moreover, social and economic factors also heavily influence a person's outlook on privacy: countries like Germany and Norway are highly developed in the areas of economy, security, education, and health [8]. Amidst such prosperity, privacy can easily rise as a priority in these nations, especially since their citizes are raised with high standards of personal freedom. South Africa, on the other hand, have poor health and security indices [8], so these necessities might take precedence for its population.

The problem with Android's permission system is that it doesn't take this diversity into account. A permission either allows a type of information or resource to be fully given to an application, or denies access to it completely. It doesn't allow, for example, an app to have access to only a portion of a device's photos (like those taken recently or stored in a particular album), the application can either see all of them or none of them. In other words, the system doesn't deal with privacy with the appropriate flexibility, it excludes many potential users whose willingness to share information lie somewhere between these two extremes, everything or nothing.

Footnote:
6. Warren, Samuel D., and Louis D. Brandeis. The right to privacy. Harvard law review (1890): 193-220.
7. Gregor, Thomas. The Mehinaku: The dream of daily life in a Brazilian Indian village. University of Chicago Press, 2009.
8. 2016 Legatum Prosperity Index™. Legatum Institute, 2016.

Index

Shopping List Apps

To further understand the necessity of a more flexible permission system, we will take a look into shopping list apps. It is a very specific type of Android applications which, although seemingly harmless, can and is used to inconspicuosly obtain valuable information from unaware users.

General Features

The most commonly found features in shopping list apps involve the ability to:

• Add groceries to your list using text input, which autofills based not only on an internal database of products, but also on the user's previous lists.
• Add quantities, prices and notes to each item on the list.
• Organize groceries into categories for an easier visualization.
• Share the list with other people, who can also add and tick off items from it.
• Backup the list, using an external (e.g., Google, Facebook and Twitter) or in-app account.

From these feature alone, it is already possible to obtain, for example:

• Frequently purchased groceries, based on how often they are added to lists, an information which can be used to track market tendecies.
• An item's expected price and quantity, an information which can be sold to third party companies to improve their product's pricing and packaging efficiency.
• The user's personal information, such as full name, age, and gender, acquired through the external or in-app account. It can be used to bolster the information obtained in the first item, increasing both its analytical and selling value.

In other words, even the simplest of applications can unpleasantly collect data from its users. Some may argue that only the oblivious wouldn't realize an app has access to their personal information when linking or registering an account (Facebook, for example, alert users of the danger). But none can deny that even the most attentive of users can become unaware their grocery list and related preferences are being collected by an application, because it only needs a network connection (and thus, a normal, automatically given permission) to do so. The permission system fails to take any action in this scenario, where unsuspecting users desiring a shopping list app can fall victim to surveillance, albeit different from the usual type.

Specific Features

These features weren't as common among shopping list applications and all require dangerous permissions (which the user needs to personally give). They involve the ability to:

• Add groceries to the list by scanning barcodes.
• Add groceries to the list by using voice commands.
• Determine nearby grocery stores and supermarkets.

As you can see, these features give the application access to powerful sensors (i.e., the smartphone's camera, microphone, and location providers). Once the appropriate permissions are granted, the permission system allows unhindered access to these resources, permitting continuous surveillance, even while the application is running in the background. The only way a user can safeguard himself in this situation is by denying the permissions, which obviously disable their related features; it is impossible to reach a compromise between the benefits brought by these features and the risk of surveillance using only the permission system.

Some companies rely on external mechanisms to reach such compromise, like writing a privacy policy. It is a statement where parties disclose various aspects of data management, such as what information is obtained, how it is used, with whom it is shared, and how it is protected. Privacy policies are proven to reduce people's concerns over sharing information [9], but also proven to not be legal binding [10]. As such, the need to improve the permission system still exists.

List Ease

List Ease is a particularly interesting shopping list application. It not only offers most of the features previously mentioned, but also the option to receive a reminder when entering stores. This new feature uses Bluetooth LE proximity beacons, which can also track with extreme precision the path taken by users inside locations using this technology, when combined with Wi-Fi and GPS.

Both List Ease and the beacons were created by inMarket, a company specialized in digital advertising based on real-time data. By giving List Ease both location and bluetooth access, inMarket create an extremely rich database of foot traffic inside stores, which can be used to determine "hot spots" with increased movimentation ideal for placing products. Big supermarket chains like Safeway and Bald Eagle already use iBeacons, and certainly use the data collected by them (List Ease already states in its privacy policy that inMarket collects location and bluetooth data for marketing and research purposes, divulging it to investment companies and corporate affiliates).

We have again a situation where users either shut down the functionalities completely, by disabling the appropriate permissions, or allow the application to constantly survey them. The most unsettling part is List Ease's privacy policy also explicitly states that "[...] we [inMarket] cannot guarantee the security of any information collected by us or submitted to us.", which of course is the truth, since no protection measure is perfect. Nonetheless, it gives off a sense of lack of confidence in keeping the users' data safe.

Footnote:
9. Andrade, Eduardo B., Velitchka Kaltcheva, and Barton Weitz. Self-disclosure on the web: The impact of privacy policy, reward, and company reputation. ACR North American Advances (2002).
10. Cherny v. Emigrant Bank, 604 F. Supp. 2d 605 - Dist. Court, SD New York 2009.

Index

Shop App and IoT

Improving the permission system in the IoT context is the priority of this work but, with the exception of the iBeacon, all of the privacy flaws previously mentioned had the Android device itself as their source. In this section we will demonstrate how one of the most popular piece of IoT technology, the smartwatch, can also be used to survey users and obtain information, while still using a shopping list application as a foundation.

Since smart watches are often used to collect information (and not store it), we will begin by listing the data a modern smart watch can obtain:

• Location (GPS)
• Movement and orientation
• Heart rate
• Hydration
• Skin temperature
• Blood pressure
• Blood oxygen levels
• Blood glucose levels
• Stress levels
• Body composition (in particular body fat)

Compared to a smartphone, which usually can only acquire the first two, a smartwatch is much more powerful when it comes to health statistics, particularly due to its constant and close proximity to the body. Allowing an application access to such information gives it an incredible amounts of power. For example, if List Ease combines its foot traffic data with users' heart rate and stress levels, it can track their emotional patterns inside stores, which in turn can be used to gauge whether customers react to specific changes (e.g., to new products, sales events, changes in layout and placement) positively or negatively. Companies would be able to maximize their profits down to minute details by getting this information from inMarket; furthermore, consequently giving them significant leverage against competitors. The application already uses the Apple Watch in its iOS counterpart (albeit not for tracking purposes), so Android smartwatch compatibility is certainly a possibility.

Permissions in Android Wear

Permissions in Android Wear, Android's operating system for smartwatches and wearables, work the same way as permissions in standard Android: they are requested all at the same time upon installation for devices running Android 5.1 or lower (or with target SDK 22 or lower), or one at a time, when the app needs them, otherwise. The difference is that, in the former case, permissions are not shared between phone and Wear applications: a Wear app still needs to request dangerous permissions even if its phone app already has them.

Issue with Android Wear Permissions

The main issue in this scenario is that the access to all these health related sensor are bundled under one permission, BODY_SENSORS, most likely due to them not being standardized among smartwatch models. An application only needs to justify using one to have access to all of them without raising much suspicion. List Ease, for example, can justify using heart rate monitors, the most commonly found sensor in smartwatches, to send users tailored product recommendations to improve their heart health; it can even inform them it is the leading cause of deaths worldwide (estimated 15 million in 2015 [11]) to increase the acceptance of this feature. In other words, this single permission possibly allows an application to obtain an absurd amount of information.

Footnote:
11. World Health Organization 2017, The top 10 causes of death, accessed 3 October 2017, http://www.who.int/mediacentre/factsheets/fs310/en/