What's on Users' Minds? Toward a Usable Smart Phone Security Model

32 PERVASIVE computing Published by the IEEE CS n 1536-1268/09/$25.00 © 2009 IEEE

S m a r t e r P h o n e S

T he increasing popularity of smart mobile phones poses new challenges in usable security. Current means of specifying policies or preferences for, say,

resource sharing, are either woefully inad-equate, in terms of what they can express, or are too hard to use—that is, too difficult for users to express what they really want. Unlike traditional computing environments, in perva-sive scenarios mobile users are likely to become

the system administrators for their devices; they’ll manage their own security rather than rely on external security man-agement services.1 This has tremendous implications for security management. There-fore, a primary requirement for smart phones must be to design

usable security supports that relieve mobile end users from management decisions they don’t understand, enabling them to properly express and translate access control policies into device- understandable rules. Not doing this could cause users to misunderstand the security implications of their actions, leading them to define security policies incorrectly or voluntarily turning off security features that are unfriendly.2

To achieve this goal, developers should keep usability and security aligned while designing

and developing mobile applications. Keeping that in mind, we present a policy model ap-proach toward usable security for smart phones, which we assess using a set of typical security-related use cases. Based on the results of a user study, we’ve analyzed typical mobile use cases and derived critical requirements for the design of a usable access control model. Our proposed policy model relies on the assumption that un-derstandability of the policy model is a neces-sary, albeit insufficient, condition for usability of the access control system implementing that model. Policies provide expressive means to translate high-level user strategies into low-level directives that a smart phone can interpret and automatically enforce.3 Our approach adopts a semantic-based policy representation to help users understand security policies and to better reflect what they really want.

mobile Phone Use-CasesAfter observing the typical usage of mobile de-vices, we’ve come to believe that the following functionalities would greatly benefit from more usable means of articulating security rules of conduct:

Document sharing• . Mobile users like to con-trol access when sharing documents (such as photographs and music) based on factors such as the recipient’s physical proximity or rela-

As smart phones users are increasingly expected to manage their own security policies, it’s becoming more important to design usable security solutions. A socially aware access control policy model will help users better understand security implications and express their wishes.

Alessandra Toninelli and Rebecca MontanariUniversity of Bologna

Ora Lassila and Deepali KhushrajNokia Research Center

What’s on Users’ minds? toward a Usable Smart Phone Security model

AprIl–JunE 2009 PERVASIVE computing 33

tionship (for example, friends versus colleagues).Notifying others of one’s activities• . Some users like others to be aware of their current situation, such as their location, availability status, and other presence information. However, us-ers might not want to share this in-formation with all their contacts. Controlling interruptions• . Users want to control interruptions or con-tact modalities. Anecdotal evidence suggests that due to the lack of ap-propriate control mechanisms, many users simply switch off their phones to avoid calls or texts.

These three use cases all lend them-selves to modeling via access control de-cisions. The idea of shared resources is common in all the cases. For example, the resources might be photographs or documents in the first scenario, bits of information about the user’s activity or location in the second, and the user’s availability—a resource that we could model as being owned and controlled by the user—in the third.

However, specifying the conditions under which certain resources can be shared with specific parties is cumber-some. When it comes to sharing, users often share too much or nothing at all. Hence, a major obstacle to adopting user-defined policies is the users’ in-ability to understand and define their own access control policies.

Smart phone users might lack the necessary technical expertise to un-derstand or define policies, or they might find it difficult to express their security management choices.2 Cur-rent access control frameworks often require a security and system admin-istrator level of technical expertise to define and manage security policies. Creating simple, user-friendly inter-faces only solves part of the problem. Regardless of the specific interface we present to the user, a semantic gap be-tween the dynamics of the user’s world and activities and the representational model underlying policy definitions

still exists. In principle, access control policy models should provide appropri-ate and comprehensive abstractions to represent resources, requesting entities and relevant access control conditions. But who will define these policies? If the answer is the mobile phone users, then it is crucial to design policy mod-els that enable users to define machine-readable policies in the same way they

naturally think of their desired access control choices.

Furthermore, a mobile user’s world is often defined in terms of his or her vari-ous social relationships (such as friends, family, or boss). Social interactions typically drive users’ access control choices with different levels of granu-larity, depending on the type of social relationship. Therefore, access control policies should be socially aware—that is, they should be expressed in terms of the user’s social context. However, even though smart phones represent the most pervasive social networking tool currently available to users, they’re equipped with security software appli-cations that are largely unaware of us-er’s social relationships.

analyzing Users’ needsSecurity and usability have rarely been successfully integrated into system de-sign and development, which has hin-dered the widespread adoption of secu-rity tools.2 Several research efforts have addressed usability problems in security systems for traditional network envi-ronments, such as access control mech-anisms, public-key infrastructures, and encryption software.2,4 Only recently have researchers addressed the problem of usable security on mobile devices,1,5 with a particular focus on privacy is-sues in location-aware applications.6

For instance, Ginger Myles and her col-leagues adopted XML-based privacy policies and user preferences to auto-mate privacy management for location information, thereby minimizing the intrusiveness of security mechanisms on user applications.7 Denise Anthony and her colleagues presented an exten-sive case study examining users’ will-ingness to share location information.8

Their study explored how privacy pref-erences vary with place and social con-text at the time location information is requested. (See the “Related Work in Smart Phone Policy Management” sidebar for more details.)

Our contribution is to empower smart phone users with the ability to configure and administer their own mobile devices using socially aware ac-cess control policies that they fully un-derstand and manage. Similar to An-thony’s research,8 we conducted a user study to derive the design guidelines of our socially aware policy model. The objective of our study was to analyze and determine

relevant factors, or decisional el-•ements that help users in their access control choices about resource sharing;actions that users manually perform •to share or disclose information about their documents or status and to filter calls and messages; andsocially meaningful elements that •play a significant role in users’ access control choices.

Our study consisted of two phases. In Phase 1, we conducted 14 one-hour face-to-face interviews to determine the typical phone usage and interruption-management patterns in the users’ daily

Our approach adopts a semantic-based

policy representation to help

users understand security policies.

34 PERVASIVE computing www.computer.org/pervasive

Smarter PhoneS

routine and their willingness to share status and location information. We also analyzed objective data by look-ing at the users’ call logs.

Phase 1’s results inspired us to do a larger study, which substantiated our preliminary analysis. In our larger study, we recruited approximately 50 partici-pants in Italy and the US to fill out an online questionnaire. (The multina-tional participants let us analyze culture-specific social behaviors and norms.) In Phase 1, our study included computer science professionals, and we noted a bias due to personal expertise while an-swering questions. To avoid this, none of our participants had a computer science related background in Phase 2.

In this article, we only focused on the last two use-case scenarios—sta-tus sharing and interruption manage-ment—because they’re socially sensitive

activities.9,10 These scenarios offered us the most useful insights into designing a socially aware policy model. In ad-dition, we consider document sharing (the first use-case scenario) simply a generalization of information sharing.

Call FilteringIn our study, roughly 70 percent of our participants didn’t like the idea of au-tomatically filtering calls based on a priori established rules; instead, they preferred to decide when the calls ar-rived. The main reasons for this are they thought it was too difficult to de-cide in advance which calls to filter and were concerned that automatic filtering would lead to a lack of control.

Despite users’ reluctance or possible inability to think in advance of which factors influence their decision to pick up calls, answers to direct questions

about picking up calls during every-day activities supported the idea of activity-based filtering (see Figure 1a). Such filtering has a strong social char-acterization because most users tend to adopt similar strategies when engaged in highly social activities, such as meet-ings, public entertainment, and phone conversations. In many cases, we ob-served that the relationship to the caller also contributes to the user’s decision, which reinforces the hypothesis that users’ choices about call filtering have strong social underpinnings.

Sharing Status InformationWe also discovered that roughly 80

percent of our participants were will-ing to share status messages (such as “busy,” “in town,” or the reason they weren’t picking up calls) with some or all contacts in their address books,

O ver the past few years significant research efforts have

addressed the issue of representing, collecting, and

providing contextual information to support context-aware ap-

plications on mobile devices. Contextphone,1 Contory,2 and the

nokia multiuser publishing environment (MupE; www.mupe.

net) are relevant examples of prototyping platforms that enable

easy, rapid development of context-aware applications on smart

phones by allowing the devices to collect contextual information

via built-in sensors. In particular, the ContextContacts applica-

tion, built on top of Contextphone, has provided us with useful

insight for our socially aware policy framework. ContextContacts

integrates presence information with normal call and messaging

services using a GuI that shows status information about users’

contacts within their address books. Many mobile, social soft-

ware applications have recently appeared that strive to facilitate

new social networks based on information exchanged through

smart phones.1 none of these systems, however, addresses ac-

cess control management issues.

The second research area relevant to our work is policy-based

system management, which has been the subject of extensive re-

search over the last decade.3 researchers have proposed multiple

approaches for policy specification, ranging from easily processed

and interpreted formal policy languages to rule-based policy nota-

tions using an if-then-else format to attribute-based policy repre-

sentation.3 In particular, recent research efforts have tried to inte-

grate semantic technologies with policy definition, thus enabling

automated reasoning over expressive policy definitions.4 Despite

supporting group- or role-based policy definition, these policy

languages aren’t suitable for specifying policies across applications

nor do they allow social data from different sources to connect.

(See the “Cross-Application policy Specification and retrieval” sec-

tion in the main text for more details.) Furthermore, none of these

policy frameworks have been implemented on smart phones.

REfEREnCES

1. IEEE Pervasive Computing, special issue on smart phones, vol. 4, no. 1, 2005.

2. O. riva, ”Contory: A Middleware for the provisioning of Context In-formation on Smart phones,” Proc. 7th Int’l Conf. Middleware, lnCS 4290, Springer, 2006, pp. 219–239.

3. IEEE Network, special issue on policy-based networking, vol. 16, no. 2, 2002.

4. G. Tonti et al., ”Semantic Web languages for policy representation and reasoning: A Comparison of KAoS, rei, and ponder,” Proc. Int’l Semantic Web Conf. (ISWC 2003), lnCS 2870, Springer, 2003, pp. 419–437.

related Work in Smart Phone Policy management


depending on the situation or their re-lationship to callers. Figure 1b shows their willingness to share status to dif-ferent caller categories.

Our study indicated that users per-ceive their location as a particularly sensitive piece of status information; only half of our participants were will-ing to share it on average. We observed relevant variations based on socially meaningful elements, such as gender (the men were less willing to share lo-cation), number of contacts in address books (those with more contacts were less willing to share location), and con-fidence with social-networking applica-tions (those using instant message ap-plications were more willing to share location). These results support the idea that users decide to share location depending on their social environment and bindings.8

Design requirementsOur study clearly confirms that users discriminate situations (in terms of caller, time, activity, and so on) when they have to make decisions about calls and status information. In other words, users have strategies in mind, albeit not always explicit, when they manage access to resources on their mobile phones. Some situations are easy to define—for example, no in-terruptions during meetings. More dynamic cases are more difficult—for example, users might use their phones in different ways if they’re expecting calls. Therefore, we can’t achieve a completely automated access control system because some situations re-quire the user’s explicit decision.

Our study shows that, even when au-tomation is possible, users find it dif-ficult to formally define the strategies they have in mind. Thus, the lack of

usable access control tools is a major obstacle to translating user strategies into policies that a smart phone can interpret and enforce. For example, Figure 1 shows that even though users’ aren’t comfortable with automated call filtering, they tend to demonstrate reg-ular filtering patterns in specific situa-tions. We believe that users would be

more willing to use call filtering if their phones made it easier to do so.

In particular, our study results let us derive several design requirements for a usable access control policy model:

Social relationships and activities •play a crucial role in users’ mental models of sharing and controlling

1. Getting ready

2. Commute

3. Meetings

4. Working in a team

5. Working on your own

6. Manual work

7. Coffee break at work

8. Lunch

9. Outdoor activities

10 Shopping

11. House keeping

12. Taking care of children

13. Dinner

14. Watching TV

15. Public entertainment

16. Social activities

17. Talking on the phone

18. Sleeping

Activ

ity

100 1209080706050No. of users403020100

Family

Friend

Partner

Work

Other

Calle

r cat

egor

y

1201008060No. of users

40200

(b)

(a) All filtered/ignored call All picked calls

Yes

No

No answers

Figure 1. Case study participants’ responses to usage-pattern queries. Our results show their (a) activity-based response to incoming calls and (b) willingness to share status with callers.


Smarter PhoneS

access to their resources.9 Figure 1 shows that our respondents tended to use the same factors (activities and relationship to the caller) in their de-cisions. Therefore, a usable policy model should be socially aware; it should be able to manage and pres-ent access control policies as social networking choices rather than sys-tem security rules.Users want to define policies that •apply to all their “friends” or to all people “depicted in this picture” rather than explicitly name each person. This kind of modeling ap-proach seems to reflect the way users tend to group similar sets of people or resources when deciding how and when to share resources with other users.10 Hence, our model should support intensional rather than ex-tensional policy definitions.A key issue isn’t only how to spec-•ify policies (such as via user-friendly GUIs) but also when and where us-ers are allowed to do so. Users expect to define and manage security poli-cies but only within the application context in which those policies make sense, not as a separate process. Our study confirmed the importance of letting users specify their policies only when needed; their aversion to automated call filtering was mainly

motivated by the inability to define how to filter calls in advance. Users should be able to defer access control decisions until they face a particular situation.11

In our study, users’ decisions about •call and status information manage-ment might depend on time, current activity, or relationship to callers, or a combination of these factors. A us-able framework should let users view

and group policies based on different criteria. For instance, users should be able to view the same policy as “who can call me when I am in a meeting” and “this person can call me in these situations.”

Using these requirements, we de-signed our access control policy model to explicitly make policies socially aware and understandable to users.

Socially aware Policy modelOur policy model achieves usability by mirroring the user’s mental process of defining access control policies. Users typically specify their policies depending on any combination of the main dimen-sions driving access control decisions. For example,

What resource is being accessed and •what are its characteristics?Who is requesting access and what are •his/her characteristics?In what context is the access request •taking place?How is the resource being accessed?•

Our model lets users specify logical relations between these foundational el-ements. In the user’s mental model, such who/what/how dimensions are typically interrelated. For example, consider this

policy: “People I know can access my pictures if they appear in them.” In such case, the user’s access decision is based on a relation between the requestor (who) and the resource being accessed (what). While traditional policy approaches generally consider these dimensions or-thogonal, our model reflects the user’s way of thinking by supporting the cross-dimensional definition of policies.

Another key feature of our model is

the ability to specify policies by taking into account social relationships, such as friendships and job connections. For in-stance, the model lets a user define a pol-icy that implies a professional relation-ship between the resource owner and the requestor: “When I am in a meeting, my phone can ring if a client calls me.”

Finally, the model supports specifica-tion and retrieval based on any of the foundational elements we’ve already dis-cussed, such as the requestor’s identity/role (who), the resource (what), or the context. This differs from other access control models that constrain the policy writer to adopt a specific grouping ele-ment (such as identity, resource, or con-text) for policy specification, retrieval, and evaluation.12

Policy representation DetailsOur model’s ability to define policies under different perspectives and to align them with users’ social needs relies on a semantic-based policy representation model.

In particular, we exploit the Re-source Description Framework, a ba-sic Semantic Web standard for ex-pressing complex data as directed, labeled graphs (www.w3.org/TR/ rdf-concepts). The RDF data model is generic and well-suited to modeling real-world phenomena. Because hu-mans think in terms of concepts and relations between concepts, RDF pro-vides a formal representation for both. In addition, RDF supports the asso-ciation of formal semantics with data models, thus enabling simple reasoning over defined concepts and relations. At the same time, RDF encourages flex-ible structured data modeling, allevi-ating the need for a strict, predefined schema that doesn’t fit human mental models, which tend to adapt to the cur-rent situation.

At a high level, we model a policy as a set of attributes with predetermined val-ues. The policy attributes describe the what, who, how, and contextual (when, where, why) dimensions. The prede-termined value could either be a fixed

Our model specifies policies by taking

into account social relationships,

such as friendships and job connections.


constant or defined as a variable with constraints over the range of values. The current state of the world where the ac-cess request takes place is also modeled in terms of attribute/value pairs where the attribute values represent the output of sensors.13 For a policy to take effect, the attribute values that define the cur-rent state have to match the definition of the policy attributes with constrained values (policy constraints).

To express the policy model’s key dimensions, we defined a simple RDF schema (see Figure 2a). specifically, the p:requestor property describes the who part, the p:resource property the what, and the p:action property the how. We repre-sent the contextual dimension by defin-ing application-specific properties (such as p: in meeting), where p is the schema’s namespace prefix.

We represent a policy as a set of RDF statements or Sparql triple patterns—subject-predicate-object triples—with each statement describing an attribute and its value. (Sparql is an SQL-like query language for RDF, see www.w3.org/TR/ rdf-sparql-query/.) Sparql triple patterns are similar to RDF triples except that each of the subject, predicate, and ob-ject can be a variable. We use the Sparql filter and join conditions to express con-ditional situations in our policy model. In particular, we use Sparql triples in case there are variables that have to be matched at policy enforcement time.

We link the set of RDF statements and Sparql triple patterns defining a policy as a graph of nodes and arcs. The policy shown in Figure 2a consists of a set of Sparql triple patterns. For ex-

ample, we express the statement, “the resource protected by the policy is the user’s attention,” using this Sparql tri-ple patterns:

(?p, rdf:type, p:Policy)(?p, p:resource, ?res)(?res, rdf:type, p:UserAttention)

The set of triple patterns compos-ing the policy is a kind of graph tem-plate, where some nodes represent variables not yet instantiated. We can read the graph template in Figure 2a as follows:

if [a policy (?p) for resource (?res) has requestor (?r)]and [the resource (?res) has owner (?o) who is in a meeting (?c) and has client(?r)]then [action (?a) of policy (?p) is permitted; thus for a call (?a) from the requestor (?r) the phone will ring].

Figure 2b illustrates an example of the current state matching the policy definition in Figure 2a. In this exam-

ple, the resource owner is Ora Lassila and the requestor is John Smith, who works for Google and is Ora Lassila’s colleague.

We use a set of RDF statements to represent the current state. Blank nodes—that is, nodes in the graph not associated with any explicit URI (namespace and identifier)—provide the necessary connectivity between the various other parts of the graph instance. For example, we express the statement, “the requestor is John Smith, who works for Google,” in terms of the following RDF triples:

(_:policynode, p:requestor, :requestornode)(_:requestornode, foaf:name, John Smith)(_:requestornode, coac:works for, Google)

where :name indicates blank nodes.We can also view Figure 2b as a pos-

sible graph matching the graph tem-plate in Figure 2a.

model UsabilityBased on the policy examples we’ve discussed, our policy model increases

(a)

p:UserAttention p:Policy

p:Call

rdf:type

rdf:type

rdf:type

p:action

rdf:type

p:resourcep:owner

p:owner

p:requestorcoac:client

?res

?r

p:Ring

p:modality

?p

p:in_meeting?c

?a?o

p:UserAttention p:Policy

p:Call

rdf:type

rdf:type

rdf:type

p:action

rdf:type

p:resource

p:requestor

p:Ring

p:modality

Ora Lassila

John Smith

foaf:name

foaf:name

C:CalendarEvent

Google

C:CalendarEvent

(b)

P: Mobile policy schemac: Calendar schemafoaf: Friend of a friend schemacoac: Colleague of a colleague

coac:works_for

p:in_meetingcoac:client

c:subject

Biweekly Project Meeting

Figure 2. RDF schema of the access control policy model. (a) Policy graph example for the policy, “When I am in a meeting, my phone can ring if a client calls me,” (b) and its corresponding graph matching policy conditions. Nodes and relationships within the dashed triangle correspond to information typically stored in the user’s address book or calendar.


Smarter PhoneS

the user’s understanding and supports socially aware policy modeling. We can implement the policy example using a policy middleware infrastructure we’re developing to support policy life-cycle management on mobile devices. In par-ticular, because usability and social-awareness concerns typically arise dur-ing policy specification, retrieval, and evaluation, we focus our discussion on these phases.

Policy SpecificationThe use of an underlying graph model lets us mirror different user perspec-tives for policy definition. In fact, the graph-based definition of policies, which doesn’t have a focus element, can be viewed, queried, and navigated in multiple directions and from different viewpoints (such as the resource, the re-questor, or other conditions like time). To help nonspecialists define RDF poli-cies and to enable policy specification directly from applications, we provide a customizable policy editor tool directly integrated into user applications. This tool provides users with simplified pol-icy templates tailored to specific appli-

cations, similar to existing solutions.14 A policy template is a custom GUI used to create (and edit) a specific policy or set of policies that hides policy represen-tation details (such as the RDF-based policy encoding) and presents end us-ers with an application-specific edit-able subset of policy elements. For ex-ample, it lets users specify a requestor, resource, and context conditions, such as socially relevant data (their relation-ship with the caller), time (in terms of a calendar entry), and device status (in terms of battery time).

In addition to specifying new policies from scratch, a user can reuse an exist-

ing policy by importing it via the policy editor and instantiating it into the cur-rent system. This feature reflects users’ tendency to adopt similar behaviors within a given social environment. Our model allows policy reuse and sharing by modeling policies and policy tem-plates as shareable resources. Once us-ers import the policy, they can use it as is or modify it so that the links be-tween certain policy elements are rede-fined based on their environments. For example, a Nokia employee might im-port a policy example from a colleague working in the same team and redefine the owner link and the specific calendar entry it applies to.

Cross-application Policy Specification and retrievalTo improve usability, a key feature of our policy framework is the integration with common user applications run-ning on mobile phones—for example, the address book and calendar. We can specify the same policy from any appli-cation that has logic related to any of the policy elements. (We define this fea-ture as cross-application policy specifi-

cation.) For example, if a user is brows-ing her calendar and editing a meeting entry, the integrated policy editor lets her define and link one or more policies to that entry. Similarly, the integration of the policy editor with the address book lets the user specify a policy ap-plying to a specific contact (or a group of contacts) by selecting that contact in the address book.

The ability to specify the same policy from different applications strongly re-lies on the graph-based nature of our policy model. In the calendar- and address-book-driven policy specifica-tion, we create the same policy graph.

While in the former case the starting point is the calendar event node, thus reflecting a context-based policy defi-nition, in the latter, the policy graph starts on the requestor node, following an identity-based approach.

retrieval and evaluationPolicy retrieval and evaluation exploit semantic reasoning over available knowledge about users and their en-vironments. In particular, because we can perform automated reasoning over social information, our model can ex-ploit additional information when re-trieving and evaluating users’ socially aware policies. Semantic languages are well-suited to represent users’ so-cial environments, as the Friend-of-a-Friend (http://xmlns.com/foaf/0.1) and Colleague-of-a-Colleague (CoaC) ini-tiatives demonstrate. For example, in our policy we use the CoaC property client. Using our previous example, let’s suppose that Ora receives a call from an unknown number. He could exploit semantically defined social information to determine his social connection with the caller. If the caller is a client of Ora’s team manager, by means of semantic-based reasoning, we can infer that he is also one of Ora’s clients as well. Group and role definitions in traditional sys-tems can’t achieve this level of social awareness.

Furthermore, our policy retrieval and evaluation can explore and link social data from different sources. This is a crucial issue in current smart phone ap-plications, where social data are typi-cally defined and managed by different applications and can’t be connected due to application boundaries. RDF graphs not only provide a uniform and seman-tically defined representation for social data but also offer the great potential to interconnect them via semantic links, thus creating a global graph of social in-formation about the user’s world. Such interconnection might be needed at the application level (between different ap-plications running on the same user’s devices) and at the social level (between

Revising existing policies reflects

users’ tendency to adopt similar behaviors

within a given social environment.


applications running on behalf of differ-ent users or organizations). For exam-ple, information about a contact in the user’s personal address book could be linked to information extracted from a corporate address book or a social net-working application such as Facebook.

Finally, our model can accommodate (possibly unforeseen) modifications and additions to existing social data, thanks to extensibility features of existing so-cial networking data schemata.

T hanks to the adoption of se-mantic technologies, smart phone users are empowered with greater policy expres-

sivity, understandability, and social awareness; policy templates simplify policy specification and reuse; and the graph-based data structure allows for easier policy grouping and viewing based on different factors. However, we’re aware that users’ tolerance to failure remains a crucial issue for a us-able access control framework. Using our study results, we’re analyzing the impact of possible failures on the pol-icy framework’s usability. We’re also working on integrating policy con-flict analysis tools and on testing the model usability in a wide set of user case studies.

ReFeReNCes 1. D.K. Smetters and R.E. Grinter. ”Moving

from the Design of Usable Security Tech-nologies to the Design of Useful Secure Applications,” Proc. Workshop New Security Paradigms (NSPW 2002), ACM Press, 2002, pp. 82–89.

2. IEEE Security & Privacy, special issue on usability and security, vol. 2, no. 5, 2004.

3. IEEE Network, special issue on policy-based networking, vol. 16, no. 2, 2002.

4. IEEE Internet Computing, special issue on useful computer security, vol. 12, no. 3, 2008.

5. D. Balfanz et al., ”Talking to Strangers: Authentication in Ad-Hoc Wireless Net-

works,” Proc. Network & Distributed Systems Security Symp. (NDSS 2002), The Internet Soc., 2002, pp. 7–19.

6. J. Hong et al., ”Guest Editors’ Introduc-tion: Security & Privacy,” IEEE Perva-sive Computing, vol. 6, no. 4, 2007, pp. 15–17.

7. G. Myles , A . Fr iday, and N. Davies,”Preserving Privacy in Environ-ments with Location-Based Applica-tions,” IEEE Pervasive Computing, vol. 2, no. 1, 2003, pp. 56–64.

8. D. Anthony, T. Henderson, and D. Kotz, “Privacy in Location-Aware Computing Environments,” IEEE Pervasive Com-puting, vol. 6, no. 4, 2007, pp. 64–72.

9. J.E. Katz and M. Aakhus, eds., Perpet-ual Contact: Mobile Communication, Private Talk, Public Performance, Cam-bridge Univ. Press, 2002.

10. A. Khalil and K. Connelly. ”Context-Aware Telephony: Privacy Preferences and Sharing Patterns,” Proc. 20th Conf. Computer Supported Cooperative Work

(CSCW 2006), ACM Press, 2006, pp. 469–478.

11. S. Voida et al., ”Share and Share Alike: Exploring the User Interface Affordances of File Sharing,” Proc. Conf. Computer Human Interaction (CHI 2006), ACM Press, 2006, pp. 221–230.

12. A. Toninelli et al., ”A Semantic Context-Aware Access Control Framework for Secure Collaborations in Pervasive Computing Environments,” Proc. Int’l Semantic Web Conference (ISWC 2006), LNCS 4273, Springer, pp. 473–486.

13. O. Lassila and D. Khushraj, ”Contextu-alizing Applications via Semantic Mid-dleware,” Proc. 2nd Int’l Conf. Mobile & Ubiquitous Systems (MobiQuitous 2005), IEEE CS Press, 2005, pp. 183–191.

14. G. Tonti et al., ”Semantic Web Languages for Policy Representation and Reasoning: A Comparison of KAoS, Rei, and Pon-der,” Proc. Int’l Semantic Web Conf. (ISWC 2003), LNCS 2870, Springer, 2003, pp. 419–437.

the AuthorsAlessandra Toninelli is a post-doctoral researcher at the university of Bolo-gna. Her research interests include semantic technologies, especially semantic-based middleware, context-aware applications, policy specification and man-agement, security for pervasive/mobile environments, and social networking. She has a phD in computer science engineering from the university of Bologna. She is a member of the IEEE and the IEEE Women in Engineering organization. Contact her at [email protected].

Rebecca Montanari is an associate professor at the university of Bologna. Her research interests include policy-based networking and systems/service management, context-aware service management, security management mechanisms, and tools in both traditional and mobile systems. She has a phD in computer science engineering from the university of Bologna. She is a mem-ber of the IEEE.

Ora Lassila is a senior data technologist at nokia Services and a member of nokia’s CEO Technology Council (a technical advisory board to the company’s top management). His research interests include various aspects of the Seman-tic Web, particularly applications of Semantic Web technologies to mobile and ubiquitous computing. He has a phD from Helsinki university of Technology. He is a member of the Association for the Advancement of Artificial Intelligence and the ACM.

Deepali Khushraj is an r&D specialist at nokia, uSA. Her research interests include next-generation Web technologies and mobile middleware. She has an MS in computer science from the university of Maryland, Baltimore County.

Documents

What's on Users' Minds? Toward a Usable Smart Phone Security Model