Mobile devices can better manage user privacy if they continuously model a user's context, but doing so can result in high energy consumption. The energy costs can be reduced by reasoning about what context information is known, what additional information is needed, how accurate it must be and how to e ciently acquire it. We model the sensors and their data properties, accuracy levels and energy costs in an RDF knowledge base supported by an OWL ontology. We describe a method to manage privacy on smartphones in an energy e cient manner by selecting the best choice sensor for maintaining the user's context information. Sensor selection is done by COntext MANager miDDleware (COMANDD), which maintains a context model and answers queries about it. Context requests are served by capability matching, accuracy level matching and selection of lowest energy cost sensor for reporting context data. A context change detection function is used to decide when the context should be updated.
Contemporary enterprise work environments are witnessing a signi cant rise
in accommodation or adoption of the Bring-Your-Own-Device (BYOD) model.
Concerns over corporate data protection has led to security rms actively
researching the challenges and opportunities of using such a model. Ionic Security,
an Atlanta based startup recently raised $9.4 million to develop its technology
for enabling employees to access data on their own devices [
Container based approaches provide security to corporate data but with larger overheads of security enhanced operating systems and separate application groups. Moreover, container based systems ignore user context and user data ow and modern smartphones are capable of much more than just storing corporate data i.e. they can gather tremendous amounts of information about the user and her context. User data and context leakage thus, becomes an enormous issue with potentially disastrous results. Naturally, we recognized the move to BYOD model as a major challenge, making privacy management on smartphones an important goal. Advances made in context modeling, location tracking and collaborative localization has resulted in emergence of a class of smartphone apps that can access and share embedded sensor and context data. Current security and privacy mechanisms on Android and other mobile operating systems are not well equipped to e ectively control dynamic data ow between the framework and the applications.
In our previous work, we showed application and user context-dependent
information sharing policies that dynamically control data ow among applications
at a ne-grained level1. We use semantically rich policies to dynamically monitor
and control the data ow between the sensors and the apps on a smartphone
[
The other challenge apart from privacy management comes from a di
erent but equally vital problem of limited battery capacity, on smartphones. One
might claim that users' computation expectations from their smartphones are
increasing every day at the same time frustrations due to phones running out
of battery remains a signi cant issue. It can also be claimed that, the ability
of batteries to power these devices are not increasing as fast as the processing
capabilities [
While policy based privacy management has its advantages, it does require
the latest context to be available at all times. Therefore requiring context to be
updated frequently. This unfortunately creates a serious hindrance due to the
limited battery capacity on smartphones. We created an app that would update
the context (location using GPS) with a high frequency and found out that the
battery can drain out as fast as ve hours, given certain conditions are true.
Energy e cient privacy management therefore becomes, an important goal. In
our ongoing work we have presented a three-fold solution towards achieving this
ultimate goal [
In this paper we focus on the solution of sensor selection to achieve energy
e ciency. We present the design of the COntext MANager miDDleware
(COMANDD) for achieving the goal. We extend a mobile ontology i.e. PlatMob [
The rest of the paper is organized as follows. Section 2 explains the threefold energy e ciency solution design. Section 3 dives into the sub-solution of sensor selection and describes the ontology that allows us to select a sensor using an example rule. Section 4 describes the methodology used for the creation of the energy model and relative accuracy values of location sensors. Section 1 Application and App are both used to refer to the same concept, of an Android App in this paper 5 summarizes the related work from the literature. Section 6 summarizes the ongoing work and concludes the paper. 2
Our three-fold solution for energy e cient privacy management is based upon a study and creation of an energy model for an Android smartphone's componentwise battery consumption pattern. The base assumption in the formation of the model is that there are more than one sensor in a smartphone that can provide the same kind of data. For example location can be obtained using a phone's GPS or Internet connection. The steps in our three-fold approach are as follows.
First, we assume a time period in which a sensing request would be coming in. During each time period, we would only enable the sensors that are required to satisfy the antecedents of relevant policy rules. And, if a set of the policy rules being enforced require the same sensor data (e.g., location) then we take one reading and use it for all of the rules.
Second, if certain information can be gathered from multiple sensors, we use the sensor with the lowest energy footprint or one that is already being used unless the requester asks for a higher precision on the data provided. We tradeo accuracy for energy e ciency depending on the granularity requested by the policy. That means, if we have implemented a policy at the current time which states that provide only country level location data then we ignore the fact that the app is requesting a ne location as provided by the GPS. If the GPS is currently not switched on, we do not consider switching it on even though the app requested GPS location since the policy clearly stated that the data to ow has to be at country level.
Third, if there are multiple conditions in the rule's antecedents and the rule is a conjunction of the conditions then negating a low cost condition will negate the whole rule. We therefore try to reorder the rule in order of the cost of the conditions in the rule's antecedents.
In this paper we have focused on the second part of this three-fold solution. The time period based context sensing step and the reordering of the conditions in the rule's antecedents are beyond the scope of this paper. 3
In an Android phone, apps can make requests for various sensor data access.
Our \Privacy Management Module" developed in previous work [
In this solution we gather and store the latest context data sensed from various sensors on the phone, in a knowledge-base using the Context Provisioning Modules. This rich context data is classi ed into four sensing groups at present. Current Android documentation broadly de nes three categories of sensors i.e. Motion, Environmental and Position. We have included a fourth category of sensed context data named location provided by the location sensors i.e. GPS, Wi-Fi and Cellular Network.
A sensor can be characterized by properties like what is the sensing capability
of the sensor or how accurate a sensor is or how much power or energy does the
sensor consume for sensing purposes. Such characteristics may be represented
in the form of an ontology. We extend the ontology names PlatMob de ned
in our previous work [
The Context Provider Service runs in the background and it receives the requests as provided by the Privacy Management Module. The requests are for context data. The input speci es the category of context data required and the accuracy level requested. The Query Engine then makes a query to the knowledge-base for a matching context data with the accuracy level required.
At this point the inference engine can take two separate solution paths. First, if the required accuracy for the context requires the highest possible level, it has to search for the most accurate context data in the knowledge-base or access the framework and provide the required data. Second, if the accuracy is lower than the accuracy level of multiple sensors from the sensor capability group then it again searches for the context data in the knowledge-base and if not found, queries the low cost sensor to provide the requested context data.
Two examples: Let's consider that the user's calendar states that user is in meetings from 9:00am to 5:00pm on a weekday at a corporate location. We also have the GPS coordinates of the user at the corporate location at 9:00am in the morning. We may now switch o the GPS and not update the location information till 5:00pm in the evening.
In another example, we have the user at his home at 6:00am in the morning on
a weekend. The user is naturally connected to her home Wi-Fi. The user activity
gathered from a learning system we developed in earlier work [
As seen from the two examples above, we can ascertain that context information can be associated with activities. Therefore, we de ne a context change detection function. The inputs to this function are an activity end time, a low cost sensor's input denoting change in user activity state. The function determines if, the current context data is stale or not. At which point we update the context and store it back to the knowledge-base for future use.
Thus, by modifying the process of continuous context update to a low frequency context update system we achieve energy e cient sensing. 4
In order to make a system on a mobile, energy e cient and making selections of sensors to be based upon energy cost of individual sensors, it is rst and foremost necessary to explore the energy consumption of individual components on a smartphone. Towards that goal we created an Android app capable of collecting data of current battery levels. The app records any change in battery levels along with the timestamps and stores the information on an external storage on the phone. We created a baseline for the bare bone Android system in airplane mode. This ensured that there was no network communication. We also ensured that no other apps were running on the system. Using Android programming constructs we ensured that the system was running only the operating system on its own and nothing else. We drained the battery out in this condition. Our technique thus provided us with battery consumption pattern which formed the baseline for our energy model.
Creation of the energy model that was carried out included the task of selecting a component that we wanted to model. Selection was done for all possible sensors in each individual sensor group (mentioned in previous section). Once a component was selected we yet again used an Android app to run that component, refreshing the data obtained over small time intervals and storing the battery level changes, timestamps and the sensor data obtained. At present we have created models for location detection sensors. Figure 2 shows the comparative battery drainage time for Wi-Fi, Network, GPS and the baseline system.
From the model we were able to calculate the average values of energy consumption of the sensors under test as follows:
The energy model data was incorporated into our extension of the place ontology explained in the previous section.
The other aspect of location sensors that we studied in our work was of
location accuracy with respect to a baseline. We observed that although
WiFi consumed relatively low energy. It showed fairly accurate location results,
given the assumption that we were able to connect to a Wi-Fi location and
even if we are connected the Wi-Fi access point has been updated to the Wi-Fi
hotspot databases. Network localization on other hand were highly inaccurate
and unstable. The high energy cost associated with the network can be attributed
to 3G data transmission energy cost. Figure 3 shows the distance predicted, from
the absolute location provided by GPS, for Wi-Fi and Network.
Privacy management: Our approach for privacy management di ers from those
in the literature [
Energy e ciency: Current work in the literature on the energy consumption
study focuses on exact battery utilization of speci c applications and also refers
to tail energy issues [
Acquisitional Context Engine (ACE) is a work done in energy e cient context inference. This work includes the notion of Inference Caching and Context Correlation Mining. In our current work we have adopted a unique approach of de ning a function that would specify that the context is outdated and needs to be updated. Given an initial location and activity context, we use a function with inputs of activity length, current time and a low cost motion sensor like accelerometer to determine whether there was any change in context or not. Thus we avoid updating context altogether by using a low energy costing sensor and avoid the need to maintain a caching mechanism.
As far as we know a cross-device context discovery framework has not been designed or implemented by anyone. We believe this new technique would allow us to achieve extended battery life beyond any current mechanisms. 6
In this paper we have described the design of an energy e cient privacy management system for smartphones running the Android operating system. We are currently working on the implementation of the middleware to support the system and designing evaluation experiments to test it. We plan to implement two separate systems with and without the context manager middleware and compare and contrast the results to evaluate our system for various privacy manager use cases.
The research work done here is based on the data that can be successfully obtained using Android framework provided data. The best precision of data available through the framework is a one percent change in the battery level. Although the expected battery drain is linear. It may not be exactly linear. We are working on other phones and carrying out research by varying the parameters that a ect accuracy and e ciency. We eventually intend to collect enough data to run a learning algorithm and generate a model le. When this model would be put on a phone it will be able to predict the energy consumption patterns of the phones components and adjust the model if necessary.
In course of our research, we observed that frequent update to location
context had a signi cant impact on the battery. GPS position x although takes
substantial time initially [
When we talk about evaluating the work, we can look at this from three di erent aspects. We have to evaluate the policies, in order to prove that the policies are capable of providing the privacy the user needs. We have to evaluate the accuracy of the user context that we gathered, in order to prove that the technique of not actually using the sensors or using inaccurate sensors to gather user context does not reduce context accuracy below a certain a threshold. Finally, we have to evaluate the energy e ciency claim for our system. At present, we are working on the evaluation of this work. We have designed two methods of carrying out the evaluation.
The rst is the ideal evaluation scenario where we plan to put our system on a number of phones. We then ask the user to use their phones with a speci c selection of privacy policies applied. We record the user's battery usage for e ciency evaluation and user's responses on a questionnaire for evaluating the privacy aspect. We do the same task without our system on the phone for a few user's and compare the results for evaluation purposes.
The second technique we have designed is to use a simulated environment for some phones and using a markov model of real human users simulate activities and location changes. Thereafter we can compare the results for an energy e ciency perspective by logging the battery usage on two phones, one with the system and one without. Such evaluations would still have to be carried out. At the moment we are in the process of creating the experimental setups and we are working on the evaluation process. 7
Support for this work was provided by NSF grant 0910838, MURI award FA955008-1-0265 from the Air Force O ce of Scienti c Research. Varish Mulwad provided valuable inputs throughout the design process of the COntext MANager miDDleware (COMANDD).