17
Technische Universit ¨ at Darmstadt Center for Advanced Security Research Darmstadt Technical Report TUD-CS-2013-0218 ConXsense – Context Sensing for Adaptive Usable Access Control Markus Miettinen, Stephan Heuser, Wiebke Kronz Ahmad-Reza Sadeghi, N. Asokan System Security Lab Technische Universit¨ at Darmstadt, Germany CASED TUD-CS-2013-0218 Technische Universit¨ at Darmstadt First Revision: August 13, 2013 D-64293 Darmstadt, Germany Last Update: August 13, 2013

Technische Universit at Darmstadt - … · yIntel Collaborative Research Institute for Secure Computing at TU Darmstadt, zTU Darmstadt / Center for Advanced Security Research Darmstadt

Embed Size (px)

Citation preview

Technische Universitat Darmstadt

Center for Advanced Security Research Darmstadt

Technical Report TUD-CS-2013-0218

ConXsense – Context Sensing for AdaptiveUsable Access Control

Markus Miettinen, Stephan Heuser, Wiebke KronzAhmad-Reza Sadeghi, N. Asokan

System Security LabTechnische Universitat Darmstadt, Germany

CASED TUD-CS-2013-0218Technische Universitat Darmstadt First Revision: August 13, 2013D-64293 Darmstadt, Germany Last Update: August 13, 2013

ConXsense – Context Sensing for Adaptive UsableAccess Control

Markus Miettinen∗, Stephan Heuser∗, Wiebke Kronz†, Ahmad-Reza Sadeghi‡, N. Asokan§∗Fraunhofer Institute for Secure Information Technology, Darmstadt, Germany,†Intel Collaborative Research Institute for Secure Computing at TU Darmstadt,‡TU Darmstadt / Center for Advanced Security Research Darmstadt (CASED),

§University of Helsinki, Department of Computer Science

Abstract—In this paper, we present the design and imple-mentation of ConXsense, a framework utilizing context sensingfor easy-to-use and adaptive context-aware access control formobile devices. Previous work often require either users tolaboriously specify detailed policies or they rely on pre-specified,non-personalized and error-prone policies for generic contextclasses. Recent approaches attempt to address these deficienciesby learning from context data. Our approach improves on this byusing context data to automatically estimate the sensitivity andsafety of the user’s context and using the estimates for dynami-cally enforcing access control rules in a highly personalized, non-intrusive and usable manner. Our initial implementation of theframework addresses two smartphone-related problem scenariosfor context-aware access control: 1) how to prevent unauthorizedapps (like sensory malware) from gathering information aboutthe context of a mobile device (contextual privacy) and 2) howto protect the data and applications on the device from physicalthreats in the context (like thieves or device misuse by others). Westart with a sociological user study, and use its results to informthe design and implementation of ConXsense. We carry out adata collection and analysis study based on which we evaluate theeffectiveness and accuracy of ConXsense. Moreover, we integrateConXsense with a fine-grained access control architecture andshow how it can effectively protect against sensory malware aswell as device theft and misuse.

I. INTRODUCTION

Mobile devices today are equipped with a wide varietyof sensors. Applications that make use of the context arebecoming increasingly popular. Examples include location-based applications like Foursquare and Google Latitude,augmented reality applications like Layar, Wikitude, GoogleGoggles HERE City Lens and many more. Even mainstreamapplications like social network apps support context-basedenhancements.

However, context information and sensing capabilities ofsmart devices also provide an attractive attack surface formisuse, as the recent development of sensory malware shows:malicious code, typically a Trojan appearing to be a legit-imate app, uses the sensors to extract sensitive informationfrom the surroundings. Prominent examples are Stealthy VideoCapturer [1] (video via camera), (sp)iPhone [2] (keystrokesvia accelerometer) Soundcomber [3] (spoken secrets via mi-crophone), or the recent PlaceRaider [4] Trojan presented atNDSS 2013 (3D models via camera). Users may also havegranted sensor access privileges to benign apps which use themtoo intrusively: for instance the user grants camera permissions

to an augmented reality app without realizing that the appmay take pictures of surroundings even when the user doesnot want to use augmented reality, as a means of enrichingthe app vendor’s data collection. At the same time, the task ofconfiguring sensible security and privacy policies is becomingincreasingly difficult for ordinary smartphone users due tothe ever-growing amount of applications and services used onsmartphones. A quick remedy for this could be the increaseduse of default policies, but these can not take the personalsecurity and privacy needs of individual smartphone usersadequately into account. Several surveys [5], [6] point outthat many mobile users do not use idle screen locks to protecttheir phones. One reason is that screen locks and other similaraccess control techniques available on mobile devices todayare both too inflexible and hard to use. Exploiting contextinformation to configure access control may address bothproblems [7].

Hence, there is a need to 1) control the use and releaseof contextual information in order to encounter threats arisingfrom, e.g., sensory malware, and, 2) to utilize available con-textual information to enable context-aware access control.

While context-aware access control is not new, mostprevious works require pre-specified policies [8], [9], [10].Context features and context detection are mainly used astriggers for activating or deactivating access control rules asspecified by these policies. Only recently have researchersstarted to explore how to improve the usability of context-aware access control by using context information moreintensively [7], [11]. Our work constitutes an advancementin this line of research, but going even further. By utilizinga sophisticated context model and data analysis methodsgrounded in real-world ground truth data, we aim at a systemthat is not only capable of triggering access control rulesbased on context, but that actually provides the capabilityto assess the security and privacy of the context itselfdynamically. We envisage that such functionality wouldbe applicable also to many other security applications onsmartphones, besides access control.

Contributions and Roadmap. Our contributions are asfollows:• A sociological survey of user perceptions as to how

the location and surroundings of a smartphone affect

the security and privacy of users (Section III). We usesurvey techniques widely accepted in the social sciencescommunity.

• The design and implementation of ConXsense, the firstcontext-aware access control framework for smart-phones that provides automatic, adaptive and personal-ized policy decisions for context dependent access control(Sections IV and VI). Our interdisciplinary approachuses the results of the sociological study to design andimplement a sophisticated context model as well as dataanalysis and machine learning techniques for estimatingthe sensitivity and safety of contexts dynamically (Sec-tion V). It also integrates them with operating systemsecurity components and uses the sensitivity and safetyassessments to select appropriate access control rules thusconstructing an end-to-end context-aware access controlsystem (Section IV).

• The application of ConXsense to two concrete use cases(Section II): protection of smartphone data by usingConXsense to dynamically configure idle screen locking,and defending against sensory malware. ConXsense,however, is applicable to a wide range of other securityand privacy-related use cases.

After summarizing related work (Section VII), we conclude(Section VIII) with some outlines of future work.

II. PROBLEM DESCRIPTION

Problem Setting. We focus on context-based access controlin two different flavors: First, we aim at protecting the in-formation in the ambient “context” of the device (i.e., theenvironment the device finds itself in) from malicious oruntrusted applications on the device. In particular, we want toprevent or limit the ability of untrusted applications to gatherinformation from contexts that are sensitive. We can furthersubdivide sensitive contexts into private contexts, where thesensitive information in the context is private to the userof the device, and confidential contexts where the sensitiveinformation belongs to someone else but the user still wantsto protect this information from untrusted apps. The user’shome is an example of a private sensitive context, whereasthe user’s workplace is an example of a confidential sensitivecontext. Second, we want to protect the applications and dataon the device from potential threats in the context: we want toensure safety for the applications and user data by limiting thepotential damage arising from someone physically accessingthe device without the user’s approval. In other words, wewant to assure privacy (case 1) as well as safety (case 2).Adversary Model. For the privacy case, the adversary isan app already installed on the device. We assume that theapplication has already been granted the necessary privilegesduring installation and has therefore access to the contextualsensors on the mobile device. The application may be a TrojanHorse (e.g., sensory malware) or a benign but somewhatintrusive application. For the safety case, the adversary is aperson in the context with physical access to the device. The

person may be malicious (a thief) or honest-but-curious (acolleague or sibling) or “clueless” (a small child).Assumptions. We assume that the user’s device is equippedwith a variety of sensors capable of recording informationabout its ambient context. This information typically includesthings like GPS location, information about WiFi accesspoints and Bluetooth devices in range, accelerometer readings,camera snapshots, audio samples, magnetometer readings,luminosity and proximity sensor readings, etc. We also assumethat the device has some form of a fine-grained access controlsystem available (such as ours), and that malware on the devicecannot circumvent the access control system. 1

Objective and validation. Our objective is to design a contextprofiling framework that can use available contextual infor-mation to automatically and dynamically configure the fine-grained access control system in order to provide protectionagainst the type of adversaries we discussed above.

With the help of our framework, the device would be able toautonomously identify relevant contexts and suitable policiesfor these contexts based on limited user feedback, without theneed for the user to explicitly define these contexts and assignpolicies to them beforehand.

In order to be successful, our framework must be able toidentify relevant contexts of the user, determine the sensitivityand safety of the context from the user’s point of view andselect appropriate access control rules for the fine-grainedaccess control system.

In the case of privacy, we want to thwart sensory malwareapplications on the affected device from collecting sensitiveinformation by using the mobile device sensors while the useris in a sensitive context. On the other hand, access to contextsensors for benign third-party apps should be restricted as littleas possible when the user is not in a sensitive context. We donot want to limit the functionality and thus the user-experienceof legitimate apps that need relevant context information tofunction properly. Similarly, in the case of safety, we wantto minimize the chances that an unauthorized person in thecontext has access to a user’s device. We will do this byconfiguring the idle screen lock dynamically based on thesafety level of the context, while trying to strike a balancebetween maximal safety and the user annoyance of having tounlock the device in safe contexts.

In both cases, we will evaluate the effectiveness of theframework by comparing how it performs against ground truthdata that we collect from a user data collection trial.

III. USER SURVEY

User perceptions of safety and sensitivity of contexts are im-portant aspects for the design of our framework. To study thefactors that influence the user’s views of safety and sensitivity,we conducted a survey that was answered by 122 participantsaged 18-56, including people from different household types

1Possible malware that would be able to use operating system (root) exploitsto circumvent the enforcement of the context-aware access control system isoutside the scope of this paper.

and representing different organizational positions, technicaland non-technical, researchers, secretaries and managers.

Following a Mixed Methods [12] approach, we designed astatistical-quantitative survey [13] using quantitative questionsto identify facts by statistical analysis [14] combined withopen-ended, qualitative questions for investigating the under-lying reasons for the perception of safety and sensitivity. Thetext of the survey questionnaire is available for reference inappendix A.

Our understanding of “safety” is adopted from social sci-ences: A private place like home is perceived as safe due tothe predictability of and control over the environment and thefamiliarity of people therein. Public places on the other hand,lack these aspects and are typically not perceived as safe [15].We explicitly exclude the notion of safety in criminal andother social contexts, and focus specifically on the notion ofsafety with regard to the usage of mobile devices. Therefore,we follow the assumption in [7] that familiar contexts withfamiliar people are “safe”, and there is no need to protectthe smartphone in such contexts (e.g., by activating the idlescreen lock). While it does not seem surprising that a highlyfamiliar place like “home” would be perceived as safe, somestudies report perceptions of another very familiar context,namely “work” to be more diverse [16]. This motivated us tospecifically investigate the differences in perceptions relatedto these contexts, “home” and “work”.

Another dimension in addition to the perception of a contextbeing “safe” or “unsafe” is the distinction between “sensitive”and “public” contexts. We consider a context “sensitive” ifits context information is private to the user or containsconfidential information so that applications on the user’ssmartphone should not have access to it without the user’sexplicit approval. For example, a person’s workplace, thedoctor’s office, and a person’s home are likely to be perceivedas sensitive environments since these contexts typically containprivate and confidential information. In contrast, a “public”context is of such generic or public nature, that it does notreveal significant private or confidential information.

With our survey, we sought to identify, which are theprimary factors affecting the perception of contexts as safeor sensitive w.r.t. to the usage of smartphones. As suggestedin earlier work [7], we aimed to particularly investigate therole of familiar contexts and familiar people as factors.Survey Results. As shown in table I, the majority of peo-ple (94% and 55%, respectively) perceive familiar contexts(Home, Work) as safe. It seems clear that the familiarity of aplace affects the perceived safety of the context positively.However, a significant fraction of people (40%) perceive“work” as “unsafe”, suggesting that the familiarity of thecontext alone is not a sufficient indicator for safety, as weshall see below.

The survey data in table I also suggest that a significantfraction of respondents (46% and 42%, respectively) feelthat a familiar context (Home, Work) is also sensitive. Thisdependency of the sensitivity of a context on the context’sfamiliarity is, however, clearly not as strong as it is for safety.

Nevertheless we consider the familiarity of a context to be afactor that affects the sensitivity of a context positively.

In table II we can see that the majority of respondents(66%) found safety to depend on people present in the context.From the responses to the open-ended questions, it is clearthat the feeling of safety is particularly caused by peoplethat are familiar to the user. Similarly, 68% of respondentssay the presence of people can also cause a context to beperceived as unsafe. Answers to open-ended questions showedthat the presence of unfamiliar people implies unpredictabilityand represents risk, leading to a feeling of unsafety. We cantherefore conclude, that the feeling of unsafe is caused by thepresence of people that are unfamiliar to the user.

Therefore, it seems that the following factors affect theperception of safety of a context: On the one hand, familiarpeople in the context cause a context to be considered safe.However, the presence of unfamiliar people in the context is areason for that context to be considered unsafe. Keeping thisin mind, we can understand, why according to table I 40% ofrespondents specified “work” as an unsafe place. While theplace “work” itself is safe as long as there are only familiarpeople around, the appearance of unfamiliar people cause theperception of a formerly safe context to change to unsafe.

From table II we see that the perception of sensitivity doesnot appear to be affected by the presence of people. Morerespondents (43% and 42% vs. 39% and 36%, respectively)believe that the people present in the context do not influencewhether the context is sensitive or public. It would thereforeseem that it is the private or confidential information oftenpresent in specific contexts that plays a more significantrole in the perception of sensivity of contexts. And in fact,confidential information is one of the main reasons given byrespondents in open-ended question answers for why a contextis considered sensitive.

TABLE I: Perceptions of Home vs. Work

Context Sensitive Public Safe UnsafeHome 46% 17% 94% 4%Work 42% 21% 55% 40%

TABLE II: Influence of people on the perceived safety andsensitivity of the context

Question Yes NoSafe depends on people 66% 14%Unsafe depends on people 68% 11%Sensitive depends on people 39% 43%Public depends on people 36% 42%

Based on the analysis of the survey results above, we canidentify following main factors affecting users’ perceptions ofsensitivity and safety:• Familiar contexts tend to be regarded as safe.• Familiar people in context tend to make contexts to be

regarded as safe.• Familiar contexts tend to be regarded as sensitive.• Unfamiliar people in context tend to make contexts to be

regarded as unsafe.

Since the familiarity of contexts and people seem to becentral factors affecting the perceptions of mobile device users,we designed our context model in a way that we can buildcontext profiles that can 1) identify relevant contexts andmodel their familiarity, and, 2) track encounters with otherpersons and identify familiar people by observing their mobiledevices. As described more closely in sections IV and V, wedesigned heuristic evaluation functions that attempt to capturethe logic behind these factors. Keeping these factors in mind,we also selected context features as input data for inductiveevaluation functions that would allow machine learning modelsto learn about user’s perceptions of sensitivity and safety andmake predictions about them based purely on the contextprofiles and incoming context information.Discussion. The analysis presented above supports our com-mon understanding of the perception of safety and sensitivityand even shows which factors influence the perception ofcontexts. However, exceptions exist, like, e.g., those 4%,who consider home (familiar context with familiar people) as“unsafe”. Reasons for this can be various. Answers to open-ended questions suggest that even in familiar contexts theperception of safety changes when untrusted people appearor it is caused by what we call the “toddler scenario”: theinfluence of familiar people (e.g., a young child, or spouse)considered as clueless or honest but curious, causing a personto prefer her device to remain protected also in familiarcontexts. To investigate these special cases, more detailedquestions on contexts that are perceived as sensitive wouldneed to be included. However, sociological literature suggeststhat statements about such contexts are perceived as intrusiveand will therefore not be answered [15], [16]. This concernwas also reflected in some responses we received about theonline questionnaire. Therefore, and because exceptional casesseem to be a marginal phenomenon, we decided to focus ourinvestigation at this point on the common cases and addressmore exceptional cases in subsequent studies.

IV. SYSTEM DESIGN

Figure 1 shows the high-level design of the ConXsensesystem. The Context Sensing Layer is responsible for acquir-ing relevant context data from the device’s sensors at regularintervals (e.g., once a minute). These data are processed bythe ContextProfiler to identify relevant context objects andaccumulate context profiles for them. The context profiles areused by the Context Evaluator to assess the sensitivity/safetylevel of the context. The Context Evaluator regularly evalu-ates two functions: the context sensitivity evaluation functionλ providing an estimate of the sensitivity of the context andthe context safety evaluation function φ providing an estimateof the safety of the context. We will show in section V, howthese evaluation functions are computed utilizing contextualdata from the environment.

The Context Evaluator furthermore continuously informsthe Access Control Layer of changes in the device’s con-text’s sensitivity/safety level as shown in Figure 2. Context-dependent access control rules for sensitive functions are

ConXSense Profiler

GPS WiFi BT Acceler-ometer

Proximity sensor etc...

Access Control Layer

Context Profiler

Profile Storage

Context Evaluator

User Feedback

Context Sensing Layer

c(t) c(t)

λ(t) φ(t)

Fig. 1: ConXsense System Design

stored in the Access Control Policy. These rules describein which contexts, more precisely in which sensitivity/safetylevel, apps of different trust levels may access sensitivefunctions. Policy Enforcement Points (PEPs) in relevantoperating system functions query the PolicyServer for accesscontrol decisions at runtime. The PolicyServer thereby actsas a Policy Decision Point (PDP) in our access controlarchitecture. Furthermore, the PolicyServer proactively for-wards changes in the current context’s sensitivity/safety levelto selected components, such as the Lockscreen, to enforcechanges in their runtime behavior.

Access-Control Layer

Trusted App

Untrusted App

PEP

Sensor API

ConXSense Profiler

Access Control Queries

Inter-Component Communication

Context Information

Lockscreen

Context Information

PEP

Camera API

Access Control Queries

Policy Server

Access Control Policy

Access Control Rules

Fig. 2: Enforcement of Context-based Policies

In Section VI we apply the ConXsense architecture intwo different use-cases: We first show how the ConXsensearchitecture can be used to protect the user from sensorymalware. We then present a context-aware device Lockscreenwhich mitigates the effects of device loss and theft.

For the correctness and usability of the framework, theperformance of the Context Evaluator is of vital importance,since the correctness of the estimates directly impacts thedegree of protection the framework provides on one side,and, the impact on the usability on the other hand. We modeltherefore the goodness of the system using following figuresof merit to estimate the performance of the framework.

Given a context c(t) at timepoint t the Context Evalua-tor evaluates regularly two functions, the context sensitivityevaluation function λ : {c(t) | t ∈ T } → {sensitive, public}

and the context safety evaluation function φ : {c(t) | t ∈ T } →{safe, unsafe}. In addition, we denote the ’true’ sensitivity andsafety levels of a context c(t) at time point t with λ(c(t)) andφ(c(t)), respectively.Protection level. The protection level that our framework pro-vides is defined by the fraction of times the system correctlyidentifies contexts as sensitive or unsafe and thus causes thesystem to enforce appropriate access control rules to protectagainst sensory malware or device theft/misuse.

The protection level πλ ∈ [0, 1] of the context sensitivityevaluation function λ is defined as the fraction of timesduring which Context Evaluator correctly identifies sensitivecontexts as sensitive:

πλ =

∑t∈T 1{sensitive}(λ(c(t)))× 1{sensitive}(λ(c(t)))∑

t∈T 1{sensitive}(λ(c(t)))

where 1A(x) is an indicator function, s.t. 1A(x) = 1, ifx ∈ A, and 0 otherwise.

Similarly, for the context safety evaluation function φ, wedefine the protection level πφ ∈ [0, 1] as the fraction of timesthe Context Evaluator correctly identifies unsafe contexts asunsafe:

πφ =

∑t∈T 1{unsafe}(φ(c(t)))× 1{unsafe}(φ(c(t)))∑

t∈T 1{unsafe}(φ(c(t)))

The higher the protection level that the evaluation functionsprovide, the better the framework is able to protect the useragainst aforementioned threats.Usability deterioration. Each time the ConXsense frameworkcauses the Access Control Layer to enforce access controllimitations because the context is estimated to be sensitive(by limiting access to sensors) or unsafe (by activating theLockscreen), the usability of the device inevitably deterio-rates. In truly sensitive/unsafe contexts this is inevitable, butwe want to limit the unnecessary enforcement of limitingaccess control rules as much as possible in order to providebetter user experience for the user in such contexts in whichstrict protection measures are not needed. To be able tomeasure the unnecessary deterioration of user experience, wedefine the following figures of merit. For the context sensitivityevaluation function λ, we define the usability deteriorationξλ ∈ [0, 1] to be the fraction of times the Context Evaluatorincorrectly identifies a public context as sensitive:

ξλ =

∑t∈T 1{sensitive}(λ(c(t)))× 1{public}(λ(c(t)))∑

t∈T 1{public}(λ(c(t)))

Similarly, for the context safety evaluation function φ, wedefine the usability deterioration ξφ ∈ [0, 1] as the fractionof time the Context Evaluator incorrectly identifies a safecontext as unsafe:

ξφ =

∑t∈T 1{unsafe}(φ(c(t)))× 1{safe}(φ(c(t)))∑

t∈T 1{safe}(φ(c(t)))

The lower the usability deterioration scores ξλ and ξφ are,the better usability for users our framework is capable toprovide.

In section VI, we will use the above figures of merit toevaluate the implementation of our system based on real datacollected from a user study. In the following, we present thecontext model based on which the input data for the sensitivityand safety evaluation functions λ and φ are generated.

V. CONTEXT MODEL

In this section, we present our context model that we applyin our current implementation of the ConXsense framework.Based on the learnings of the user survey (section III), webase our context model on two important aspects: i) LocationContext and Contexts of Interest (CoI) for modeling contextsand their familiarity and ii) the Social Context for modelingfamiliar and unfamiliar people in context.Contexts-of-Interest (CoI). For our purpose, Contexts-of-Interest (CoIs) correspond to locations that a user visits oftenand/or spends a significant amount of time in, e.g., home,workplace, grocery store, etc. Some places might be bestidentified by profiling the GPS observations and identifyinggeographical areas that accumulate particularly many GPSobservations. For other CoIs, however, especially for CoIslocated indoors, using GPS alone might not be feasible, sincethe structure of buildings often obstructs reception of requiredGPS signals. Therefore, such CoIs are better identified byusing the set of WiFi access points observed at these locationsas ’signatures’ for the CoI. Hence, we adopt both GPS andWiFi as means for identifying CoI and use them in parallel tocapture important places of the user.Social context. In order to capture different social contexts ofusers, we model people in the user’s surroundings throughtheir mobile devices that can be sensed through proximitysensing technologies like Bluetooth (BT).

To capture only devices that are typically carried by persons,we filter the BT observations by their device class so that weconsider only mobile devices like cell phones, headsets, PDAsand other portable devices.

In the following we will define the metrics and algorithmsfor measuring the above parameters and how to validatethem to estimate the context the user is in. For the reader’sconvenience, the relevant parameters used in the following def-initions can be found in concise format also in the Appendix,Table IV.

A. Detection of Contexts of Interest (CoIs)We consider two kinds of CoIs: GPS-based CoIs which

are geographical areas on the surface of the earth, and WiFi-based CoIs that are characteristic sets of WiFi access pointsusually observed in a specific place and thus identifying theRF environment there. GPS CoIs capture significant places ofthe user in outdoor areas, and WiFi CoIs cover also indoorlocations in urban areas, where typically coverage of WiFiaccess points is available. By combining both types of CoIs,we are able to identify and detect most significant places thatusers typically visit.

1) GPS-based CoIs: The identification of GPS-based CoIsis based on position observations posi = (lati, loni) obtainedvia GPS.

We denote with t(posi) ∈ N the timestamp associated withthe observation, and with dist(posi, posj) the geographicaldistance of position observations posi and posj .

The sequence of GPS observations is divided into GPS staypoints, which represent visits of the user to different places,during which the user stays within a radius of rsp from thefirst GPS observation. In order for a visit to be considered astay point, the visit is also required to last longer than t minsp

and not to contain observation gaps longer than t gapsp .Definition 1 (GPS stay point): A GPS stay point gps sp =

(pos1, pos2, . . . , posn) is a sequence of position observationsposi, such that ∀i, 1 < i ≤ n : dist(pos1, posi) ≤ rsp andt(posi) − t(posi−1) ≤ t gapsp and dur(sp) = t(posn) −t(pos1) ≥ t minsp .

We calculate for each stay point an average position possp

as the average of all position observations belonging to thestay point, i.e., possp = (latsp, lonsp), s.t. latsp =

∑nk=1 latkn ,

and lonsp =∑n

k=1 lonk

n . The average position of a stay pointrepresents the predominant location where the user has beenlocated during her visit to the stay point.

The average positions possp of individual stay points areaggregated to form rectangular geographical areas of at mostgpsmax width and length. An area is a GPS-based Context-of-Interest, if (i) the user has visited the area more than f mincoi

times and (ii) has spent in the area longer than t mincoi intotal. More formally,

Definition 2 (GPS-based CoI): Let us denote a rectangulararea with Ci = (latmin, lonmin, latmax, lonmax) and letgps sp(Ci) denote the set of stay points sp whose averageposition possp is contained in Ci. The area Ci is a GPS-basedCoI, if following conditions hold:(1) |gps sp(Ci)| ≥ f mincoi ,(2)∑

spj∈gps sp(Ci)dur(spj) ≥ t mincoi ,

(3) latmax− latmin ≤ gpsmax ∧ lonmax− lonmin ≤ gpsmax .An observation pos falls in CoI Ci, if latmin ≤ latpos ∧lonmin ≤ lonpos ∧ latpos ≤ latmax ∧ lonpos ≤ lonmax.Example. As an illustrative running example, let us considera user who is a full-time working professional, regularly com-muting between her place of work and home, predominantlyusing public transport. Other places she regularly visits are agrocery store close to her home, a public sports facility and thehome of a close relative. She usually carries her smartphonewith her, which continuously senses her context and contextdata of her GPS location and WiFi access points.

Assume now, our example user goes to the grocery storeand stays there for 32 minutes, i.e., longer than t minsp = 10minutes and moves only within a radius of rsp = 100 meters,a stay point sp (Def. 1) of duration dur(sp) = 32 minuteswill be generated. The average of all position observationsposi during the stay point visit will be the stay point averageposition possp , most likely located in or near the grocery store.Waypoints along her daily commuting routes, however, would

not generate any stay points, since on her way she does notspend sufficiently long time in the same limited area.

Now, if our user visits the grocery store 10 times and stayseach time for 32 minutes, ten stay points will be generated withaverage positions possp located in or near the grocery store.These average positions will be aggregated into a GPS-basedCoI C (Def. 2), because their total stay duration of 5 hours and20 minutes is longer than the required t mincoi = 30 minutesand there are more than the required f mincoi = 5 stay pointsfalling inside the CoI. The area of the CoI will be the smallestrectangle containing all the stay point average positions possp

associated with the stay point visits. The same holds for GPS-based CoIs covering, e.g., her home or the sports facility.

Note that our notion of stay points and CoIs is not boundto a stationary life. Also frequent travelers would obtain GPS-based CoIs over time, given that they visit the same places(e.g., airports or hotels) often enough and spend sufficientlylong time there.

2) WiFi-based CoIs: For identifying WiFi-based CoIs,WiFi access point observations rf i are used. Each observationconsists of the MAC address of a detected WiFi accesspoint and the timestamp of the observation, which we denotewith t(rf i). The sequence of individual WiFi observations isdivided into WiFi snapshots, which are subsequences corre-sponding to observations obtained during a single WiFi scanof duration t maxwifi .

Definition 3 (WiFi Snapshot): A sequence of WiFi accesspoint observations rf i that occur within t maxwifi consti-tute a WiFi snapshot, denoted as wifi . That is, wifi =(rf 1, rf 2, . . . , rf n), such that t(rf n) − t(rf 1) < t maxwifi .We denote with t(wifi) the first timestamp belonging to thesnapshot, i.e., t(wifi) = t(rf 1).

Following the notion of stay points for GPS observations,we extend this concept to WiFi and divide the sequence ofWiFi snapshots into so-called WiFi stay points. The similaritybetween snapshots is determined by calculating the Jaccarddistance2 between the first snapshot and subsequent snapshotsone-by-one. As long as the Jaccard distance between thesnapshots is less than or equal to 0.5, which means that theintersection of the snapshots is at least as large as half oftheir union, the subsequent snapshots are assigned to the staypoint. The staypoint is considered complete, if the Jaccarddistance to new WiFi snapshots grows beyond 0.5 or there isa gap between consecutive WiFi snapshots that is longer thant gapsp .

Definition 4 (WiFi Stay Point): A WiFi stay point wifi spis a sequence of WiFi snapshots wifi , in which each snapshothas a Jaccard distance of less than or equal to 0.5 to the firstsnapshot of the sequence, no consecutive snapshots have atime difference larger than t gapsp , and the duration of thesnapshot is greater or equal to t minsp :wifi sp = {wifi1,wifi2, . . . ,wifin}, such that(1) ∀i, 1 < i ≤ n : Jδ(wifi1,wifi i) ≤ 0.5,

2The Jaccard distance measures the dissimilarity between sets. It is calcu-lated for two sets A and B as Jδ(A,B) =

|A∪B|−|A∩B||A∪B|

(2) t(wifi i)− t(wifi i−1) ≤ t gapsp , and(3) dur(wifi sp) = t(wifin)− t(wifi1) ≥ t minsp .These criteria for WiFi stay points were selected, because itis not uncommon that WiFi access points are missed by thecontext scan [17]. This is apparently not dependent on thesignal strength of the missed access point, so one needs totake into account that even very strong access point beaconswill be missed from time to time.

Each WiFi stay point has a characteristic set of access pointschar(wifi sp) which includes those access points that occurat least in half of all WiFi snapshots belonging to the staypoint.

Definition 5 (Characteristic Set): A characteristic setchar(wifi sp) of WiFi access points rf for WiFi stay pointwifi sp is defined aschar(wifi sp) = {rf i| count(rf i,wifi sp) ≥ |wifi sp|

2 },where count(rf i,wifi sp) = |{wifik ∈ wifi sp|rf i ∈wifik}|.A set of access points is a WiFi-based CoI, if there are at leastf mincoi WiFi stay points having this set of access points astheir characteristic set of access points, and the stay pointshave a duration of at least t mincoi in total.

Definition 6 (WiFi-based CoIs): Let C be a set of WiFiaccess points and wsp(C ) be the set of WiFi stay points thathave C as their characteristic set, i.e.,wsp(C ) = {wifi sp | char(wifi sp) = C}.The set C is a WiFi-based CoI, if following conditions hold:(1) |wsp(C )| ≥ f mincoi , and(2)∑

wifi sp∈wsp(C ) dur(wifi sp) ≥ t mincoi .A WiFi snapshot wifi falls within CoI C , if Jδ(C ,wifi) ≤ 0.5.

When our example user arrives at her workplace, a WiFisnapshot wifi is recorded. This snapshot and following snap-shots having a Jaccard distance of less than or equal to 0.5 tothe first one form a WiFi stay point wifi sp, given that the timedifference of the first and last snapshot is greater than t minsp

and there are no gaps in the WiFi snapshot observations longerthan t gapsp . The characteristic set char(wifi sp) of accesspoints of this stay point consists of access points mostlyobserved at the workplace. During subsequent visits to theworkplace, more WiFi stay points with the same characteristicset will be generated. If at least f mincoi such stay pointshave been observed and the total visit duration dur(wifi sp)of these stay points reaches t mincoi , the characteristic setconstitutes a WiFi-based CoI for the user’s workplace.

B. Context Detection

Once the GPS- and WiFi-based CoIs have been identified,new incoming GPS, WiFi and Bluetooth observations can beused to identify the location context and social context of theuser at any point in time. These are required in order to beable to model, which places a user has visited and which otherpeople the user has encountered.

1) Location context: We first define the notions of visitsand visit time, which are required to determine, when and forhow long a user has been visiting a particular CoI.

Definition 7 (Visits): A user’s visit VC to a GPS-basedCoI C = (latmin, lonmin, latmax, lonmax) is a sequence ofposition observations posi = (lati, loni) falling within theCoI and having timestamps at most εV apart from each other:VC = (pos1, pos2, . . . , posn), where ∀posi ∈ VC : latmin <lati ∧ lonmin < loni ∧ lati < latmax ∧ loni < lonmax, and∀i, 1 < i ≤ n : t(posi) − t(posi−1) < εV . Similarly, a visitVC to a WiFi-based CoI C is a sequence of WiFi snapshotswifi falling within the CoI and having timestamps at most εVapart from each other. That is, VC = (wifi1,wifi2, . . . ,wifin),where Jδ(C ,wifi i) ≤ 0.5 and ∀i, 1 < i ≤ n : t(wifi i) −t(wifi i−1) < εV . We denote the set of all visits VC of theuser to CoI C with VC .

In our running example, whenever our user arrives at herworkplace, a WiFi snapshot wifi (or a position observationpos) will fall into the workplace CoI. Beginning from thissnapshot (or position observation) all subsequent observationsfalling within the CoI will be part of a visit V to the CoI, aslong as the time distance between consecutive snapshots (orposition observations) is less than εV = 5 minutes.

Definition 8 (Visit Time): We define the visit time TV ofa visit V to consist of the sequence of timestamps fallingbetween the first and last position observation or wifi snapshotbelonging to the visit. That is, TV = (t1, t2, . . . , tn), suchthat ∀ti : t(pos1) ≤ ti ≤ t(posn) for GPS-CoI visits andt(wifi1) ≤ ti ≤ t(wifin) for WiFi-CoI visits. If a visit Vconsists of only a single position observation or WiFi snapshot,i.e., V = (posi) or V = (wifi i), we assume that the visitcovers a timespan of half of the duration of the scanninginterval tscan: TV = (ti−k, ti−k+1, . . . , ti, . . . , ti+k−1, ti+k),where ti+k − ti−k = tscan

2 and ti = t(posi) or ti = t(wifi i),respectively.

Following this definition, the visit time TV of a visit Vof our example user to the grocery store CoI C covers alltimestamps ti starting from her arrival, i.e., the timestamp ofthe first WiFi snapshot t(wifi1) (or GPS observation t(pos1))falling into the CoI up until to when she leaves the CoI, i.e.,until the timestamp t(wifin) (or t(posn)) of the last WiFisnapshot wifin (or GPS observation posn) that falls into theCoI.

Definition 9 (Location Context): A location context Lt attimestamp t is the set of CoIs C that the user is visiting duringthat point of time, i.e., for which there exists a visit V , whosevisit time TV contains t, i.e., Lt = {C | ∃V ∈ VC : t ∈ TV }Note, that CoIs can be overlapping, which means that a usercan be visiting several CoIs simultaneously. If the user isnot visiting any of the CoIs at a specific point in time, thecorresponding location context will be empty.

Definition 10 (Familiar CoIs): The set of Familiar CoIsCfam is the set of all such CoIs that are particularly importantfor the user, that is, CoIs where he has spent longer thant minfamcoi of time during at least f minfamcoi visits. Thatis, Cfam = {C1,C2, . . . ,Cn}, such that ∀Ci ∈ Cfam :∑V ∈VCi

TV ≥ t minfamcoi ∧ |VCi | ≥ f minfamcoi .For our example user, familiar CoIs would be identified atplaces like her home or her workplace, since she has visited

these places more often than f minfamcoi = 5 times and hasspent altogether longer than t minfamcoi = 60 minutes duringthese visits.

2) Social context: The notions of encounter and encountertime are required in order to be able to identify, which devices(representing other people) and for how long the user’s mobiledevice has encountered, so that a distinction of familiar andunfamiliar people in the social context can be made.

Definition 11 (Encounters): An encounter Ed of a user witha device d is a sequence of Bluetooth observations bt i ofdevice d with timestamps that are at most εE apart from eachother: E = (bt1, bt2, . . . , btn), where ∀i, 1 < i ≤ n : bt i =d∧t(bt i)−t(bt i−1) < εE . We denote the set of all encountersof the user with a device d with Ed .

When our example user arrives at her workplace, her deviceobtains a Bluetooth observation bt1 = d of her colleague’sdevice d . This observation and any subsequent device obser-vations bt i = d of the colleague’s device form an encounterEd with the colleague’s device, as long as the time distancebetween consecutive device observations is less than εE = 5minutes.

The purpose of allowing gaps of at most εE = 5 minutesis to be able to handle missed device observations (which arenot uncommon with Bluetooth sensing) without breaking acontiguous sequence of device observations into two separateencounters too easily.

Definition 12 (Encounter Time): We define the encountertime TE of an encounter E to consist of the sequenceof timestamps falling between the first and last device ob-servation of the encounter. That is TE = (t1, t2, . . . , tn),such that ∀ti : t(bt1) ≤ ti ≤ t(btn). If an EncounterE consists of a single device observation, i.e., E = (bt i),we assume that the encounter covers a timespan of half ofthe duration of the scanning interval tscan and set: TE =(ti−k, ti−k+1, . . . , ti, . . . , ti+k−1, ti+k), where ti+k − ti−k =tscan

2 and ti = t(bt i).The encounter time TE of an encounter of our example user

with the device of her colleague would cover all timestampsbeginning from timestamp t(bt1) of the first observation bt1

of the colleague’s device, up until timestamp t(btn) of the lastobservation btn of the colleague’s device, made immediatelybefore she leaves work and the colleague’s device gets out ofrange.

Definition 13 (Device Context): A device context Dt attimestamp t is the set of devices d that are encountered duringthat point of time, i.e., for which there exists an encounter E,whose encounter time TE contains t, i.e., Dt = {d | ∃E ∈ Ed :t ∈ TE}.

Definition 14 (Familiar Devices): The set of familiar de-vices Dfam is the set of all such devices that the user hasencountered at least f minfamdev times and for which thetotal duration of the encounters is at least t minfamdev . Thatis, Dfam = {d1, d2, . . . , dn}, such that ∀di ∈ Dfam :∑E∈Ed TE ≥ t minfamdev ∧ |Ed| ≥ f minfamdev .Familiar devices d for our example user would be the

mobile devices of familiar people like her spouse or her

colleagues at work which she has encountered more oftenthan f minfamdev = 5 times and the total duration of theseencounters is longer than t minfamdev = 30 minutes.

However, a mobile device of a person like the member ofthe house cleaning service at her office would not become afamiliar device, since even though that person’s device mightbe encountered nearly daily, the encounters would typically beof such short duration that they would not aggregate significantamounts of total encounter time.

C. Context Profiles

Based on the above context model, the following contextprofiles are aggregated for the user: a CoI profile CoIs and adevice profile Devs . The CoI profile CoIs = {C,Cfam,P}consists of the set of all identified CoIs C, the set of fa-miliar CoIs Cfam and mapping P : C → N × R,C 7→(visitsC , durC ) providing the total amount of visits visitsC

and total duration of visits durC to each CoI C ∈ C.Similarly, the device profile Devs = {D,Dfam,O} consists

of the set of all encountered devices D, the set of familiar de-vices Dfam and a mapping O : D → N×R, d 7→ (encd , durd)providing the total amount encd and total duration durd ofencounters with each device d ∈ D.

D. Context Evaluation Functions

Using the above context profiles, we instantiate two alter-native versions of the context evaluation functions λ and φintroduced in section IV: heuristic and inductive.

1) Heuristic evaluation functions: In section III, we iden-tified the major factors affecting the user’s perceptions ofcontext sensitivity and safety. Following these factors, weformulate following heuristics for evaluating the sensitivityand safety of contexts:(a) If one is in a familiar CoI, the context is sensitive.(b) If one is in a familiar CoI, the context is also safe, unlessthere are unfamiliar devices in the context.

Definition 15 (Heuristic Sensitivity Evaluation): Let c(t) =(Dt,Lt) denote the context of the user’s device at timestampt. The heuristic evaluation function for sensitivity λheur(c(t))evaluates context c(t) as sensitive if any CoI C in the currentlocation context Lt is a familiar CoI. That is

λheur(c(t)) =

{sensitive Lt ∩ Cfam 6= ∅public Lt ∩ Cfam = ∅

Definition 16 (Heuristic Safety Evaluation):The heuristic evaluation function for safety φheur(c(t)) eval-uates context c(t) as safe if the user is in a familiar CoI andat most d maxunfam devices d in the device context Dt arenot familiar. That is

φheur(c(t)) =

{safe |Dt −Dfam| ≤ d maxunfam

unsafe otherwise.

2) Inductive evaluation functions: The inductive evaluationfunctions λind and φind utilize statistical machine learningmodels that are based on supervised learning. This means thatthe models are trained with labeled training vectors (label , ~tr),where ~tr = (f1, f2, . . . , fn). The labels for the training vectors

are obtained from user feedback, i.e., from events where theuser of the device has provided explicit feedback about theperceived sensitivity and safety of the context:

Definition 17 (User Feedback): A user feedbackfb(t) at timepoint t is a tuple (fbsens , fbsafe), where fbsens ∈{sensitive, public} and fbsafe ∈ {safe, unsafe}.

For each user feedback event fb(t), a training vector ~tr(t) isgenerated based on the context c(t). The components fi (alsocalled features) of ~tr(t) are calculated based on the currentcontext at time of the feedback event, c(t) = (Lt,Dt) and theaggregated context profiles CoIs and Devs . The values of theindividual components of the training vectors ~tr are detailedin table III.

The training vectors are used to train two classifier modelsM , one for predicting the sensitivity of a context, Msens, andone for predicting the context’s safety, Msafe.

M asens = train(a, Fsens), M a

safe = train(a, Fsafe)

where a denotes the used machine learning algorithm andFsens = ((fbsens(t1), ~tr(t1)), . . . , (fbsens(tn), ~tr(tn))) andFsafe = ((fbsafe(t1), ~tr(t1)), . . . , (fbsafe(tn), ~tr(tn))) denotethe sequences of labeled training data vectors. Using thetrained classification models, we can now define the inductivecontext evaluation functions λ and φ as follows:

λ(c(t)) = classify(a,M asens, ~e(t))

φ(c(t)) = classify(a,M asafe, ~e(t))

where ~e(t) = (f1, f2, . . . , fn) denotes an evaluation vectorderived from the context c(t) and the context profiles CoIsand Devs . The components of the evaluation vector are thesame as for the training vectors ~tr and are detailed in table III.

VI. IMPLEMENTATION AND EVALUATION

Our implementation of ConXsense is based on the AndroidOS and comprises three main components: 1) a Context DataCollector app for mobile devices which collects contextualdata and ground truth feedback; 2) A ContextProfiler forpreprocessing and evaluating the collected data and generatingpredictions about the sensitivity/safety of contexts; 3) AnAccess Control Layer based on the FlaskDroid architec-ture [18] which enforces context-dependent access controlpolicies using the context predictions of the ContextProfiler.

A. Context Data Collector

1) Implementation: Our Context Data Collector app forthe Android operating system uses a background Serviceto collect context data in intervals of 60 seconds. This is arequired tradeoff between the battery lifetime and the quantityof the collected data, since for the data collection we aim at abattery lifetime of at least 12 hours. The collected context datacomprises location information (GPS, WiFi and cellular net-work triangulation), nearby Bluetooth devices and WiFi accesspoints, acceleration sensor information as well as information

about user presence and her interaction with apps (Activities).3

In order to evaluate the context evaluation algorithms, theContext Data Collector app also collects ground truth datafrom the participating users. The users regularly report theirperceived sensitivity and safety of the current context in oneof the following ways (cf. Figure 3): 1) The participantsuse context feedback buttons on the device’s UI; 2) NFCtags provided to the participants are used to trigger contextreporting; 3) If no ground truth data has been provided by theuser in the last two hours, the app reminds the user to do sovia sound, vibration and flashing LED notifications. Contextand ground truth data are stored in a SQLite database andperiodically uploaded to a server via HTTPS.

(a) Feedback using ContextFeedback Buttons

(b) Feedback using ContextNFC Tags.

Fig. 3: Android Data Collector App

2) Evaluation: We installed the Context Data Collectorapp on the Android smartphones of 15 test users. We thencollected data over a period of 18-68 days from differentusers, 56 days per user on the average. The total datasetcontained data from 844 distinct user days. On the average,users provided ground truth feedback on 46 days of the datacollection period, resulting in a ground truth dataset containing3757 labeled data points about the sensitivity of the context.Based on early results of the user survey we conducted inparallel, we decided to also incorporate feedback about theperceived safety of the context to the Context Data Collector.Thereby, the ground truth dataset could be enriched with 1861labeled data points providing also feedback about the users’perception of the safety of the context.

Since our test participants tended to spend most of theirtime in contexts that are sensitive and/or safe, the distributionsof ground truth are also skewed towards sensitive and safefeedbacks. 80.44% of the ground truth feedback specifiedcontexts as being sensitive and 19.56% as public. For ’safety’the distribution was 81.84% for safe and 18.16% for unsafe.

Some users had provided only very little feedback for

3Context Data Collector is a generic solution collecting more data thanrequired for the current ConXsense algorithms.

TABLE III: Features for training the inductive evaluation classifiers

Feature name Descriptionf1 max-gps-coi-visit-time Maximum visit time of any GPS-based CoI in Ltf2 nbr-gps-coi-visits Number of visits to GPS-based CoI with maximum visit timef3 max-wifi-coi-visit-time Maximum visit time of any WiFi-based CoI in Ltf4 nbr-wifi-coi-visits Number of visits to WiFi-based CoI with maximum visit timef5 nbr-btdev Number of Bluetooth devices in Dt, i.e. |Dt|f6 nbr-fam-btdv Number of familiar Bluetooth devices in Dt, i.e. |Dt ∩ Dfam|f7 avg-encounter-time Average encounter time of familiar devices in Dtf9 avg-nbr-encounters Average number of encounters of familiar devices in Dt

some ground truth classes (especially for public and unsafe).Training a classifier with too few data points for a class wouldnot provide meaningful results, and therefore we decided toreject such users’ ground truth datasets from our evaluationwhich did not contain at least 10 data points in a ground truthclass. Hence, we had to remove the data of four participantsfrom the sensitivity dataset, so that our evaluation datasetcontained a total of 3512 labeled data points (319.2 per useron average). For the ground truth dataset for safety, eightparticipants had provided sufficient amounts of feedback, sothat the evaluation dataset for safety contained finally a totalof 1551 labeled data points (193.9 points per user on average).

3) Battery lifetime: During the data collection a batterylifetime of at least a working day (12h) was reported by theusers on Samsung Galaxy Nexus and Nexus S devices, whichwe consider reasonable since no optimization regarding powerconsumption has been performed yet.

B. Context Profiler

1) Implementation: We implemented the functionality ofthe ContextProfiler as off-line data processing scripts utilizingbash shell scripting, awk and Python. The scripts were usedto identify individual GPS and WiFi CoIs for each user, and tocalculate the familiarity of Bluetooth devices that the users hadencountered during the data collection period. The heuristiccontext evaluation functions were also implemented as dataprocessing scripts. The scripts were also used for extractingthe feature vectors for training and evaluating the inductiveevaluation functions which were realized and evaluated by us-ing the Weka data mining suite [19] and its provided algorithmimplementations for k-NN, Random Forest and Naıve Bayesclassfiers.

2) Evaluation: The heuristic evaluation functionsλheur(c(t)) and φheur(c(t)) were run on all contextobservations c(t) for which also ground truth feedbackfb(t) was available. The outputs of the heuristic evaluationfunctions were then compared with the ground truth fb(t)and the protection levels πλheur and πφheur and the usabilitydeterioration measures ξλ and ξφ (cf. section IV) werecalculated.

The same input data were used also to investigate threealternative inductive context evaluation functions based onpopular classifier algorithms: λkNNind and φkNNind utilizing a k-nearest neighbour (kNN) classifier, λNBind and φNBind , based on aNaıve Bayesian classifier and λRFind and φRFind using a Random

Forest classifier.The k-nearest neighbours (kNN) classifier bases its pre-

diction on comparing a testing datapoint to the n closestobservations to it in the training dataset. The prediction is themost frequent class label in this set of observations. The NaıveBayes classifier is a simple probabilistic classifier which hasbeen successfully used, e.g., in spam e-mail detection [20].Random Forest is an ensemble method, that is commonlyused for classification tasks. It randomly picks subsets ofinput attributes and trains decision trees for them. It uses themost frequently predicted label provided by this set of treeclassifiers as the final prediction.

The inductive context evaluation functionsλkNNind , λNBind , λ

RFind and φkNNind , φNBind , φ

RFind were tested using

10-fold cross-validation and the above-mentioned figures ofmerit were calculated for each algorithm and each user. Theresults of the evaluation are shown in figure 4.

As can be seen from figure 4a, all tested context evaluationfunctions provide reasonable results for context sensitivity pro-tection levels, the best results being provided by the RandomForest and k-NN classifier-based functions (average of bothbeing > 0.9). However, looking at the usability deteriorationmetrics in figure 4c, one sees that these evaluation functionspay a high price for their high protection level: the level ofusability deterioration is for many users very significant (av-erage being > 0.6). The Bayesian classifier-based evaluationfunctions shows significantly better performance in this regard(average being 0.18), but also has to acknowledge a lowerprotection level (average being 0.63). Somewhat surprisingis, how well the very simple heuristic evaluation functionsperform in sensitivity evaluation: even though the heuristiccontext sensitivity function provides relatively high protectionlevels (average being 0.74), the usability deterioration mea-sures remain acceptably moderate (average being 0.27).

For safety evaluation, the situation is very different. As seenin figure 4b, both Random Forest and k-NN classifier-basedevaluation functions fail to provide sufficient protection levels(average being < 0.40). This has probably to do with thefact that contrary to the sensitivity case, here the evaluationfunctions are required to predict the more infrequent (unsafe)context labels correctly. The only evaluation functions thatperform adequately with regard to safety protection level arethe Bayesian classifier-based and heuristic-based evaluationfunctions (showing average protection levels of 0.86 and0.98, respectively). Of these, however, only the Bayesian

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

0,80

0,90

1,00

24 59 286 317 427 448 468 677 724 737 990 Average

Random Forest

k-NN

Bayesian

heuristic

(a) Protection level of sensitivity evaluation πλ.

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

0,80

0,90

1,00

24 59 286 317 427 468 677 990 Average

Random Forest

k-NN

Bayesian

heuristic

(b) Protection level of safety evaluation πφ.

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

0,80

0,90

1,00

24 59 286 317 427 448 468 677 724 737 990 Average

Random Forest

k-NN

Bayesian

heuristic

(c) Usability deterioration of sensitivity evaluation ξλ.

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

0,80

0,90

1,00

24 59 286 317 427 468 677 990 Average

Random Forest

k-NN

Bayesian

heuristic

(d) Usability deterioration of safety evaluation ξφ.

Fig. 4: Protection level and usability deterioration for sensitivity and safety evaluation functions λ and φ

classifier-based evaluation function shows also an acceptablylow usability deterioration measure, as can be seen from figure4d.

C. Access Control Layer

1) Implementation: For our Access Control Layer weadopt and adapt the FlaskDroid [18] architecture, a fine-grained mandatory access control framework for Android 4.0.4(cf. Figure 2). FlaskDroid extends Security Enhanced An-droid (SEAndroid) [21] with fine-grained context-aware typeenforcement on Android’s middleware layer. In FlaskDroid,Android components which provide access to sensitive re-sources, such as the SensorService which provides access tosensor information, are modified to act as UserSpace ObjectManagers (USOMs) which control access to the resourcesthey manage. More specifically, USOMs control access fromsubjects (i.e., apps) to objects (e.g., data) they manage usingtypes assigned to subjects and objects. Thereby USOMs actas Policy Enforcement Points (PEPs) in our architecture.

FlaskDroid uses an Access Control Policy (cf. Figure 2)which describes types and access control rules. An access con-trol rule defines whether a certain subject type may performan operation on an object type of a certain object class.In addition, FlaskDroid supports context-dependent accesscontrol rules by means of ContextProviders – softwarecomponents which evaluate the current context of the deviceand activate/deactivate rules at runtime.

At boot time, the PolicyServer (cf. Figure 2) parses the

Access Control Policy and translates it into an in-memoryrepresentation. It proceeds to assign app types (e.g., trustedor untrusted) to all installed apps based on application meta-data, such as the package name or the developer signature.Applications installed by the user are assigned correspondingtypes during the installation process. Whenever apps accessan USOM at runtime, for example the SensorService toquery the device’s sensors or the CameraService to takepictures, the USOM queries the PolicyServer, which is partof Android’s SystemService, for access control decisions.

To meet our goals we extended FlaskDroid with additionalUSOMs. We furthermore implemented a ContextProviderwhich feeds context tags from the ConXsense ContextProfilerinto Flaskdroid’s PolicyServer (cf. Figure 2), which in turnactivates/deactivates access control rules at runtime.

To mitigate, respectively reduce the effects of sensorymalware, such as Placeraider [4] or SoundComber [3], accesscontrol on the sensors of a device is required. For example,Placeraider uses the device’s camera and the accelerationsensor to covertly construct 3D images of the surroundingsof the user. To mitigate the effect of Placeraider, we ex-tended Flaskdroid to perform access control in Android’sCameraService using a corresponding USOM which filtersqueries to the takePicture and startPreviewMode methodsbased on the type of the calling app. Furthermore, we usedFlaskdroid’s access control on sensors to filter events deliveredto SensorEventListeners registered by apps. It should benoted that in Flaskdroid’s original implementation the enforce-

ment points in the SensorManager Java class are insufficientto block sophisticated attacks, since the SensorManager classis executed in the context of (potentially malicious) apps.Thus, we replaced Flaskdroid’s SensorManager USOM witha corresponding USOM in Android’s native SensorService.Similarily, the combination of ConXsense and FlaskDroid canbe used to address other variants of sensory malware, suchas Soundcomber, by identifying the relevant Android APIs,instrumenting them as USOMs and extending the FlaskDroidpolicy with corresponding context-dependent access controlrules.

To allow for changes in the Android Lockscreen policybased on the current privacy context, we modified the Policy-Server to proactively propagate context tags to the AndroidLockscreen component. We modified Android’s Lockscreencomponent to automatically dismiss the Lockscreen when thedevice is used in a safe environment, while still showing theLockscreen in unsafe environments.

2) Evaluation: We evaluate the effectiveness and perfor-mance of our Access Control Layer in two use cases: 1)preventing sensory malware from gathering sensitive sensorinformation in sensitive contexts, and 2) enhancing the usabil-ity of Android’s Lockscreen security feature using contextinformation. For this evaluation we used a Samsung GalaxyNexus smartphone equipped with FlaskDroid for Android4.0.4 and the ConXsense extensions.

2a) Mitigation of Sensory Malware: PlaceRaider [4] is asensory malware which generates 3D models of the user’s sur-roundings by combining acceleration sensor information withcamera pictures. PlaceRaider registers listeners in Android’sSensorManager to get notified about changes in the orien-tation of the device. When a significant orientation change isdiscovered, PlaceRaider takes a picture using the Camera APIwithout user notification. It then uploads the picture and thecorresponding sensor information to an external server. Whenenough pictures are collected, the server constructs a 3D viewof the surroundings of the user.

To demonstrate the feasibility of ConXsense we designeda FlaskDroid policy which assigns the type trusted to allpre-installed system apps (e.g., the camera app), and the typeuntrusted to all third-party apps installed by the user. In areal-world scenario this trust level could be derived from thereputation of the app in an app market. Our context-dependentaccess control rules state that access to the CameraServiceand SensorService USOMs is generally allowed for all appsin public contexts but is prohibited in sensitive contexts forall untrusted apps.

We tested our implementation using a slightly modifiedversion of the PlaceRaider malware generously provided to usby its authors.4 By installing the malware on our device andlogging the context information and access control decisionswe verified that FlaskDroid successfully filtered all data de-livered from Android’s SensorService and CameraServicecomponents to the untrusted PlaceRaider app when the device

4The original PlaceRaider malware is incompatible with Android 4.0.4.

was used in a sensitive context, thus rendering the attack futile.We further verified that trusted apps could still use the sensorsand the camera. No false positives or false negatives emergedduring the evaluation of the Access Control Layer, which isnot surprising since it merely enforces the context-dependentaccess control rules.

To evaluate the performance impact we implemented anapp which automatically triggers 10000 access control queriesby reading sensor data and taking pictures. On average, ourFlaskDroid based Access Control Layer caused an over-head µ of 4.886 ms (standard deviation σ 17.593 ms) forthe SensorService and CameraService USOMs. The highstandard deviation σ is caused by Dalvik’s garbage collector:By analyzing Android’s system logs we verified that duringthe irregularly slow access control queries responsible for thehigh standard deviation the garbage collector caused a stall.Overall, 95% of all access control decisions are handled inless than 4.2 ms (cf. Figure 5), which we consider reasonable.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 50 100 150 200 250 300

Time in ms

Performance Impact

Fig. 5: Cumulative distribution of the Access Control Layerperformance

2b) Context-Aware Device Lockscreen: Android providesdifferent methods for locking the device whenever the powerbutton is pressed or the device is not used for a pre-definedamount of time. However, the locking mechanism is static anddoes not respect the current usage context: When used in asafe context, it might be desirable to enforce relaxed securitypolicies which do not require the user to manually unlock thedevice using a PIN or password. However, when a context isunsafe, the Lockscreen must always be displayed. On stockAndroid, the user might be tempted to disable the Lockscreenregardless of the current context, which is problematic in casethe device is stolen or lost.

We instrumented Android’s Settings component to be no-tified by Flaskdroid’s PolicyServer about context changes bymeans of a Broadcast Intent. To enforce context-based accesscontrol rules we modified the LockPatternKeyguardViewclass to query the Settings component for the current value ofthe safety property. If the context is considered safe and hencethe Lockscreen should not be active, the LockPatternKey-guardView class automatically dismisses the Lockscreen. Wefurthermore added a low-watermark mechanism to ensure that

whenever an intermediate unsafe context has been detectedor the device has been rebooted, the Lockscreen is alwaysdisplayed regardless of the current context’s safety property.The low-watermark mechanism is required to prevent anattacker from unlocking a locked device stolen in an unsafecontext by moving it to a context the owner considers safe.

We instrumented the LockPatternKeyguardView class tolog when the Lockscreen was displayed and when it wasdismissed. We further modified the system to periodicallywake the device from sleep and switch on the screen. Inan automated testbed we verified that the Lockscreen wasautomatically dismissed whenever the context was consideredsafe unless an intermediate or current unsafe context has beendetected or the device has been rebooted.

VII. RELATED WORK

Covington et al. [8] introduce a policy framework incor-porating context attributes in a smart home access controlsetting. They utilise a Generalised Role Based Access Con-trol (GRBAC) model and Environment Roles activated bycontext observations to adapt access control decisions. Theydemonstrate an XML-based definition language for the accesscontrol policies, but require those to be set up and maintainedmanually through a GUI tool.

Hull et al. [22] present the Houdini framework for speci-fying and enforcing context-dependent privacy policies. Theyintroduce rule-based policy management to mitigate the com-plexity that value-based customization of policies would im-ply. User-provided preferences are used to generate rulesfor privacy enforcement. They mention also support forautomatically-learned preferences that would be transformedinto rules, but do not provide support for such automation atthe time of writing.

Damiani et al. [23] introduce a spatially-aware RBAC modelusing location as a component for access control decisions.They focus on the theoretical aspects of the model and donot address, how the required access control rules would becreated and maintained in real-world implementations.

A recent patent application by Bell et al. [24] discloses asystem which enables to specify context-triggered policies en-forced on mobile devices controlling the access of applicationsto sensors and other resources on the smartphone. Also in theirapproach the access control policies are either pre-specified orare uploaded to the devices by external entities.

Conti et al. [9] describe the CRePe framework for Androidfor enforcement of context-dependent access control policies.The policies are expressed in the form of rules, which allow ordeny access to specific resources depending on the currentlydetected active context. Also they do not address, how the rulesshould be created or updated. In the MOSES framework [10]Rusello et al. propose a combination of dynamic taint trackingusing the TaintDroid architecture [25] and policy enforcementon Android’s middleware layer to enable context based accesscontrol on resources and apps with the goal of providingisolated environments called security profiles. Similarly, theTrustDroid [26] architecture proposed by Bugiel et al. provides

lightweight security domain isolation on Android with basicsupport for context-based network access control policies.In Saint [27], the authors describe a context-aware fine-grained access control framework for Android, which focuseson enabling app developers to define context-dependent run-time constraints on Inter-Component Communication betweenapps. Nauman et al. present Apex [28], a modification of theAndroid operating system which extends the standard permis-sion system with conditional permissions. It provides to someextent support for context-based access control by allowingthe user to define context-dependent resource restrictions (e.g.,based on the time of day).

In contrast to MOSES, TrustDroid and Apex, our accesscontrol architecture is based on the more generic and flexibleFlaskDroid platform [18], which is also able to cover (mostof) the use cases described in Saint, and, more importantly,our work focuses on the automatic prediction of the activesecurity context of a device using a probabilistic approachbased on heuristics and machine learning algorithms.

Riva et al. [11] use various contextual cues to estimate thelikelihood that the legitimate user of a device is in proximityand use this to configure the idle screen lock. Although wehave the same use case, our approach is based on estimatingthe safety of the context, rather than inferring the presence ofthe user.

Hayashi et al. [29] introduce Context-Aware Scalable Au-thentication, an approach which uses the location of thedevice as a passive authentication factor in a probabilisticframework to determine the active authentication factors to beused for user authentication (e.g., PIN or password) on smart-phones. While the context-aware Lockscreen implemented inConXsense resembles their approach, our approach is differentin that it builds on relatively complex modeling of dynamiccontexts aiming at determining the dynamic safety level of thecontext based on several context features. In contrast, theirapproach utilizes a comparatively simple context detectionmethod that requires users to explicitly name and classifycontexts as “home”, “work” or “other”. Their safety classi-ficaton of distinct contexts is also static and depends purelyon locations and safety labels users have provided for theselocations.

Danezis [30] proposes an approach for automatically defin-ing privacy settings in social networking applications. Therein,security contexts are determined by analyzing the social graphsof users and identifying highly connected subgraphs. The iden-tified subgraphs are used as a basis for social network securitysettings. Similarly to us also, Danezis justifies the need forinferring privacy policies automatically by the overwhelmingburden that managing security settings imposes on the user.

Sadeh et al. [31] investigate a policy definition and manage-ment system for the PeopleFinder application. They argue, thatusers are not very successful in defining privacy policies ontheir own, reaching only accuracy levels of around 60-70% forthe policy sets that they initially define and refine. They alsouse case-based reasoning (CBR) and Random Forest classifiersin making policy decisions, reporting significant improvement

over user-defined policy sets. In a follow-up work, Kelley etal. [32] introduced a user-controllable policy learning systemthat builds on incremental policy improvements proposed tothe users based on recorded history events.

Bai et al. propose a solution for fine-grained usage controlon Android [33]. Their work extends the UCON access controlmodel [34] by using context information (e.g., location andtime) as an additional input for policy decisions. While theyfocus on the implementation of a generic context-aware usagecontrol framework, we focus on the automatic prediction of theactive security context based on the surroundings of a device.

Kang et al. [35]. introduced the idea of time-based clusteringof position observations underlying our method of identifyingstay points. The concept of stay points and stay regions wereintroduced by Zheng et al. [36] and developed further byMontoliu et al. [37]. We have adopted a slightly modifiedform of the notion of stay areas in our concept of GPS-based CoIs. We also extend the notion of a stay point to non-locational data in the form of WiFi stay points. The use ofWiFi fingerprints for identification and detection of places hasbeen reported by Dousse et al. [17]. We use key learningsfrom them and adopt a simplified version of their schemeconsidering only intersections of WiFi snapshots for our WiFi-based CoI detection.

Gupta et al. [7] were the first to use context profiling.Our work extends their work in several ways: First, theydid not have reliable ground truth data whereas our datacollection produced reliable ground truth data; second, theyonly attempted heuristic techniques to predict safety but weuse both heuristic and inductive techniques and we predictboth safety and sensitivity. Finally, we integrated ConXsenseinto a fine-grained access control enforcement architecture anddemonstrated its effectiveness.

VIII. CONCLUSIONS AND FUTURE WORK

In this paper, we described how we designed and im-plemented ConXsense, a framework for adaptive and easy-to-use access control. We demonstrated its effectiveness intwo ways: by collecting ground truth data and using it toevaluate our ConXsense context evaluation algorithms andby applying ConXsense, integrated with a fine-grained accesscontrol architecture, to defend against sensory malware andpotential device misuse. ConXsense can be extended in anumber of directions which we are currently working on: Oneaspect is extending the context model and context evaluationto enable personalization of individual contexts. This willmake it possible to address also the “toddler-scenario” that wealluded to earlier. Moreover, having validated the effectivenessof ConXsense context evaluation, the next step is to evaluateits usability. We plan to implement on-device versions ofour context evaluation algorithms and create a downloadablemobile app that we can use for user studies focusing on theusability aspects related to our framework.

REFERENCES

[1] N. Xu, F. Zhang, Y. Luo, W. Jia, D. Xuan, and J. Teng, “Stealthyvideo capturer: a new video-based spyware in 3g smartphones,”

in Proceedings of the second ACM WiSec, ser. WiSec ’09. NewYork, NY, USA: ACM, 2009, pp. 69–78. [Online]. Available:http://doi.acm.org/10.1145/1514274.1514285

[2] P. Marquardt, A. Verma, H. Carter, and P. Traynor, “(sp)iPhone:decoding vibrations from nearby keyboards using mobile phoneaccelerometers,” in ACM CCS. ACM, 2011, pp. 551–562. [Online].Available: http://doi.acm.org/10.1145/2046707.2046771

[3] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang,“Soundcomber: A stealthy and context-aware sound trojan for smart-phones,” in NDSS, 2011, pp. 17–33.

[4] R. Templeman, Z. Rahman, D. Crandall, and A. Kapadia, “PlaceRaider:Virtual theft in physical spaces with smartphones,” in NDSS, Feb. 2013.

[5] C. Camp, “The BYOD security challenge: How scary is the iPad, tablet,smartphone surge?” WeLiveSecurity Blog post, February 2012.

[6] R. Siciliano, “More than 30% of people don’t password protect theirmobile devices,” McAfee Blog Central, February 2013.

[7] A. Gupta, M. Miettinen, N. Asokan, and M. Nagy, “Intuitive securitypolicy configuration in mobile devices using context profiling,” inSocialCom/PASSAT. IEEE, 2012, pp. 471–480.

[8] M. Covington, P. Fogla, Z. Zhan, and M. Ahamad, “A context-awaresecurity architecture for emerging applications,” in Computer SecurityApplications Conference, 2002. Proceedings. 18th Annual, 2002, pp. 249– 258.

[9] M. Conti, V. Nguyen, and B. Crispo, “CRePE: Context-RelatedPolicy Enforcement for Android,” in ISC 2011, ser. LNCS, vol.6531. Springer, 2011, pp. 331–345. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-18178-8 29

[10] G. Russello, M. Conti, B. Crispo, and E. Fernandes, “Moses: supportingoperation modes on smartphones,” in Proceedings of the 17th ACMsymposium on Access Control Models and Technologies, ser. SACMAT’12. New York, NY, USA: ACM, 2012, pp. 3–12. [Online]. Available:http://doi.acm.org/10.1145/2295136.2295140

[11] O. Riva, C. Qin, K. Strauss, and D. Lymberopoulos, “Progressiveauthentication: deciding when to authenticate on mobile phones,” inProceedings of the 21st USENIX Security Symposium, 2012.

[12] A. Tashakkori and C. Teddlie, Handbook of Mixed Methods in Social& Behavioral Research. SAGE Publications, 2003.

[13] C. Teddlie and A. Tashakkori, The Quantitative Tradition: Basic Ter-minology and two Prototypes. SAGE Publications, 2009, ch. 1, pp.5–6.

[14] B. Alan and E. Bell, Business Research Methods. Oxford UniversityPress, Incorporated, 2007.

[15] U. Beck, Risk Society: Towards a New Modernity, ser. In: associationwith Theory, Culture & Society. SAGE Publications, 1992. [Online].Available: http://books.google.de/books?id=QUDMaGlCuEQC

[16] S. Cohen and L. Taylor, Escape Attempts: The Theory and Practiceof Resistance in Everyday Life. Taylor & Francis, 1992. [Online].Available: http://books.google.de/books?id=-ijAXz4QCxwC

[17] O. Dousse, J. Eberle, and M. Mertens, “Place Learning via Direct WiFiFingerprint Clustering,” in Mobile Data Management (MDM), IEEE 13thInternational Conference on, 2012, pp. 282–287.

[18] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and fine-grainedmandatory access control on Android for diverse security and privacypolicies,” in 22nd USENIX Security Symposium (USENIX Security ’13).USENIX, 2013.

[19] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. H.Witten, “The weka data mining software: an update,” SIGKDD Explor.Newsl., vol. 11, no. 1, pp. 10–18, Nov. 2009. [Online]. Available:http://doi.acm.org/10.1145/1656274.1656278

[20] M. Sahami, S. Dumais, D. Heckerman, and E. Horvitz, “A bayesianapproach to filtering junk e-mail,” in Learning for Text Categorization:Papers from the 1998 workshop, vol. 62, 1998, pp. 98–105.

[21] S. Smalley and R. Craig, “Security Enhanced (SE) Android: BringingFlexible MAC to Android,” in NDSS. The Internet Society, 2013.

[22] R. Hull, B. Kumar, D. Lieuwen, P. Patel-Schneider, A. Sahuguet,S. Varadarajan, and A. Vyas, “Enabling context-aware and privacy-conscious user data sharing,” in Mobile Data Management, 2004.Proceedings. IEEE International Conference on, 2004, pp. 187 – 198.

[23] M. L. Damiani, E. Bertino, B. Catania, and P. Perlasca, “GEO-RBAC: Aspatially aware RBAC,” ACM Trans. Inf. Syst. Secur., vol. 10, no. 1, Feb.2007. [Online]. Available: http://doi.acm.org/10.1145/1210263.1210265

[24] M. Bell and V. Lovich, “Apparatus and methods for enforcement ofpolicies upon a wireless device,” US. Patent 8254902, Aug. 2012.

[25] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel,and A. N. Sheth, “Taintdroid: an information-flow tracking system forrealtime privacy monitoring on smartphones,” in Proceedings of the 9thUSENIX conference on Operating systems design and implementation,ser. OSDI’10. Berkeley, CA, USA: USENIX Association, 2010,pp. 1–6. [Online]. Available: http://dl.acm.org/citation.cfm?id=1924943.1924971

[26] S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A.-R. Sadeghi,and B. Shastry, “Practical and lightweight domain isolation onandroid,” in Proceedings of the 1st ACM workshop on Securityand privacy in smartphones and mobile devices, ser. SPSM ’11.New York, NY, USA: ACM, 2011, pp. 51–62. [Online]. Available:http://doi.acm.org/10.1145/2046614.2046624

[27] M. Ongtang, S. Mclaughlin, W. Enck, and P. Mcdaniel, “Semanticallyrich application-centric security in android,” in In ACSAC 09: AnnualComputer Security Applications Conference, 2009.

[28] M. Nauman, S. Khan, and X. Zhang, “Apex: extending androidpermission model and enforcement with user-defined runtimeconstraints,” in Proceedings of the 5th ACM Symposium on Information,Computer and Communications Security, ser. ASIACCS ’10. NewYork, NY, USA: ACM, 2010, pp. 328–332. [Online]. Available:http://doi.acm.org/10.1145/1755688.1755732

[29] E. Hayashi, S. Das, S. Amini, J. Hong, and I. Oakley, “Casa:context-aware scalable authentication,” in Proceedings of the NinthSymposium on Usable Privacy and Security, ser. SOUPS ’13. NewYork, NY, USA: ACM, 2013, pp. 3:1–3:10. [Online]. Available:http://doi.acm.org/10.1145/2501604.2501607

[30] G. Danezis, “Inferring privacy policies for social networking services,”in AISEC Workshop at ACM CCS, 2009, pp. 5–10.

[31] N. Sadeh, J. Hong, L. Cranor, I. Fette, P. Kelley, M. Prabaker,and J. Rao, “Understanding and capturing people’s privacy policiesin a mobile social networking application,” Personal and UbiquitousComputing, vol. 13, pp. 401–412, 2009. [Online]. Available: http://dx.doi.org/10.1007/s00779-008-0214-3

[32] P. G. Kelley, P. H. Drielsma, N. M. Sadeh, and L. F. Cranor, “User-controllable learning of security and privacy policies,” in ACM CCS,2008, pp. 11–18.

[33] G. Bai, L. Gu, T. Feng, Y. Guo, and X. Chen, “Context-aware usage con-trol for android,” in Security and Privacy in Communication Networks.Springer, 2010, pp. 326–343.

[34] R. Sandhu and J. Park, “Usage control: A vision for next generationaccess control,” in Computer Network Security. Springer, 2003, pp.17–31.

[35] J. H. Kang, W. Welbourne, B. Stewart, and G. Borriello, “Extractingplaces from traces of locations,” SIGMOBILE Mob. Comput. Commun.Rev., vol. 9, no. 3, pp. 58–68, Jul. 2005. [Online]. Available:http://doi.acm.org/10.1145/1094549.1094558

[36] V. W. Zheng, Y. Zheng, X. Xie, and Q. Yang, “Collaborative location andactivity recommendations with gps history data,” in WWW, M. Rappa,P. Jones, J. Freire, and S. Chakrabarti, Eds. ACM, 2010, pp. 1029–1038.

[37] R. Montoliu, J. Blom, and D. Gatica-Perez, “Discovering places ofinterest in everyday life from smartphone data,” Multimedia Tools Appl.,vol. 62, no. 1, pp. 179–207, 2013.

APPENDIX ASURVEY QUESTIONNAIRE

The purpose of this questionnaire is to study the perceptionsof smartphone users about risks of misuse related to theirsmartphones. We are especially interested in these risks fromthe perspective of surroundings factors of the smartphone.We consider the following two main aspects:1. “place” is a physical location where the smartphone is ata given instance.2. “situation”: is a particular configuration of a place (interms of the people and objects present in that place at agiven instance)We would like to ask you to consider two kinds of risks:1. Physical misuse: Somebody steals your smartphone orsomebody uses it without your permission.

2. Improper data capture by an application: An applicationthat is installed on your smartphone collects informationabout your place or situation and sends it to an external partywithout your permission or knowledge. This external partycan thereby gain potentially sensitive information about youand the places you visit.When answering the questionnaire, please consider followingdefinitions:- Context information: is any information that your smartphonecan collect using its sensors. These include, e.g., your location,the Bluetooth devices around you, the WiFi access pointsaround you, camera image snapshots, sound samples fromyour smartphones microphone, readings of the movementsensor (the accelerometer) of your smartphone, etc.We will provide further explanations during the questionnaire.

(Explicit instructions were included for most questions -questions about basic demographic features of the respondentsare excluded here for brevity.)

1) Which places you visit through your daily routine doyou expect to be “safe”?

2) Which places you visit through your daily routine doyou expect to be “unsafe”?

3) Do you experience your workplace as a “safe” place?4) Please explain why your workplace is “safe” or “un-

safe”.5) Does your experience of places or situations as “safe”

depend on people surrounding you?6) Please give examples of when your experience of places

or situations as “safe” depends on peole surroundingyou or tell us why people have no influence on yourperception of “safe”.

7) Please give examples of when your experience of placesor situations as “unsafe” depends on peole surroundingyou or tell us why people have no influence on yourperception of “unsafe”.

8) Do you experience a place as “safe” when there arefriends or people you know well surrounding you?

9) Do you experience a place as “unsafe” when there arestrangers surrounding you?

10) Does your feeling of a place or situation being “safe”or “unsafe” change during different times of day?

11) Please give examples of when you think the time of dayaffects your feeling of “safe” and “unsafe” or why timeof day has no effect on your perception.

12) How well do you think you can asses the risk of yourmobile device being stolen or misused?

13) Do you think that the risk of your mobile device beingstolen or misused might change depending on where youare?

14) Is there any tool or app installed on your phone thatprotects your smartphone and data in the case yourmobile device gets stolen or misused?

15) If you have a tool or app installed, please let us know

TABLE IV: Overview of Parameters used in the Context Model

Name Description Example valuersp max radius for GPS observations within a Stay Point 100 meterst minsp min duration of visit to an area for it to be considered a Stay Point 10 minutest gapsp max length of gap in GPS observations allowed in a Stay Point 5 minutesgpsmax max width and length of a GPS-based CoI 100 metersf mincoi min number of visits to a place for it to be considered a CoI 5t mincoi min total time spent in a place for it to be considered a CoI 30 minutest maxwifi WiFi observations within this time window belong to a single WiFi snapshot 10 secondsεV max length of gap between CoI observations allowed within a visit V 30 minutesf minfamcoi min number of visits to CoI for it to be considered familiar 5t minfamcoi min total time of visits to CoI for it to be considered familiar 60 minutesf minfamdev min number of encounters for a device for it to be considered a familiar device 5t minfamdev min total time of encounters for a device to be considered a familiar device 30 minutesεE max length of gap between device observations allowed within an encounter E 5 minutestscan Scanning interval of context scans 60 secondsd maxunfam max amount of unfamiliar devices in familiar context still considered safe 0

which one(s). If you have no app installed, pleaseexplain why you havent installed one.

16) Which places you visit through your daily routine doyou expect to be “sensitive”?

17) Which places you visit through your daily routine doyou expect to be “public”?

18) Do you experience your workplace as a “sensitive”place?

19) Please explain why your workplace is “sensitive” or not.20) Does your experience of places or situations as “sensi-

tive” depend on people surrounding you?21) Please give examples of when you think “sensitivity”

depends on peole or why it does not depend on people.22) Does your experience of places or situations as “public”

depend on people surrounding you?23) Please give examples of when you think a place is

“public” because of the presence of people surroundingyou or tell us why people have no influence on yourperception of “public”.

24) Do you experience a place as “sensitive” when there arefriends or people you know well surrounding you?

25) Do you experience a place as “public” when there arestrangers surrounding you?

26) Does the time of day affect your feeling of “sensitive”and “public”?

27) How well do you think you can asses the “sensitivity”of a place or situation?

28) Do you believe that “sensitivity” might change depend-ing on where you are?