Cross-platform access control formobile web applications

John Lylelowast Salvatore Monteleonedagger Shamal Failylowast Davide Pattidagger and Fabio RicciatoDaggerlowast Department of Computer Science University of Oxford firstlastcsoxacukDagger Innovation and Industry Relations Telecom Italia fabioricciatotelecomitaliait

dagger Department of Electrical Electronic and Computer Engineering (DIEEI) University of Catania firstlastdieeiunictit

AbstractmdashWeb browsers are a common platform for deliv-ering cross-platform applications However they currently failto provide consistent access control for security and privacysensitive JavaScript APIs such as geolocation and local storageThis problem is exacerbated by new HTML5 APIs and theincreasing number of personal devices people own and use In thispaper we present the webinos platform which aims to providea single cross-device policy system for web applications on awide range of web-enabled devices including TVs smartphonesin-car systems and PCs webinos solves the existing deficienciesin web authorisation by introducing the concept of a personalzone the set of all devices and services owned by a particularuser All devices in this zone can synchronize their access controlpolicies through interoperable middleware and can create flexiblerules which may refer to an individual user device or theentire zone We provide details of the architecture and explainhow our experience during design highlighted several conceptualchallenges

I INTRODUCTION

Web applications are gaining access to an increasing amountof important functionality Thanks to growing support for newHTML5 standards such as JavaScript APIs for geolocationdata sensors and local storage web applications have thepotential to replace native applications in many situations [1]Proponents of web applications will also claim that thereis a potential security advantage the web browser providesa sandbox isolating each page from the local device Thiscompares favourably with relatively unrestricted native code

However the web browser (or web runtime) was not orig-inally designed for complex applications and its sandboxsecurity model must be broken to accommodate the newJavaScript APIs Unfortunately HTML5 API specifications [2]do not provide detail about how authorisation should be im-plemented beyond a requirement for consent and revocationleaving this as an implementation option for each browseror user agent Considering the number of new APIs underdevelopment ndash access to cameras address books calendarsand network information [3] ndash as well as the wide range ofsecurity and privacy implications they have for both individualand corporations there is a pressing need for new standardsfor web application access control

Any access control system for web applications must takeinto consideration the fact that people own and use severaldifferent devices often at the same time More types of deviceare becoming web-enabled including smartphones tablets in-car systems (such as the BMW ConnectedDrive [4]) games

consoles and smart TVs Each will need to implement autho-risation for new HTML5 API requests taking into accountthe unique user interface and interaction patterns that thedevice offers For example an in-car system might be voiceactivated and notify the user of a new access control requestthrough audio A television might be more context-sensitivechanging interaction method depending on whether the userwas watching a movie or casually channel-hopping Moreoverthe rise of lsquosecond screenrsquo companion applications ndash whichallow TV-watchers to interact with the programme throughtheir smartphones and tablets ndash might enable more interestingauthorisation decisions affecting both devices It also seemsreasonable that any access control decision made by a user onone device might also be synchronised with others For exam-ple if a user grants a web application permission to accessthe address book on their smartphone they probably want toallow the same application access to the address book on theuserrsquos PC Web application access control must therefore beflexible enough to support different devices and interactionswhile allowing the synchronisation of user policies betweeneach device

Browsers are beginning to support synchronization of accesscontrol decisions (Google Chrome for example) but these failto account for the many different contexts of use associatedwith each device For example a lsquoprompt every timersquo policyfor geolocation data may be appropriate on a smartphone ndashwhere current location changes ndash but would be irritating ona TV There are also many ways of notifying mobile usersabout privacy events [5] and the most appropriate methodwill be context sensitive These requirements are difficult toaddress with ad-hoc browser settings which only allow limitedauthorisation decisions and synchronisation options

We assert that users require but currently lack a commonway of managing with web application permissions Standardcross-device access control policies which can address webAPIs while also being transferable to different devices areneeded This would enable devices to create custom userinterfaces but still produce interoperable authorisation deci-sions which could then be synchronised between devicesThis in turn would let users make access control decisionsinfrequently (where the same decision applies to multipledevices) but would also allow decisions based on device-specific interactions and context

In this paper we describe the architecture and implemen-

tation of webinos a cross-device web application platformwebinos is designed to give web developers access to astandard set of APIs for device features as well as providing acommon policy model for access control It also aims to giveusers a lsquoseamlessrsquo experience by providing better connectivitybetween devices The platform is targeted at four domains PCmobile in-car and smart TVs We have developed an XACML-based system which provides a single policy enforcementmechanism for a userrsquos personal zone ndash the devices theyown and use Our main contributions are the introductionof a personal zone architecture the definition of a modifiedXACML policy system to support this abstraction on alldevices and several observations from design experience

We begin in Section II by discussing the state of the artin access control and policy enforcement for mobile webapplications and web widgets In Section III we describethe requirements for a personal cross-device authorisationsystem and give an introduction to the webinos personalzone model Following this Section IV describes the webinospolicy framework and section V covers four of the conceptualchallenges faced during design and development Finally insection VI we conclude

II BACKGROUND

A Web applications widgets and browser security

A web application in a mobile context is a web page orcollection of web pages delivered over HTTP which usesserver or client-side processing to produce an application-like experience within a web browser [6] In comparisonweb widgets are interactive applications for displaying andorupdating local or remote data packaged to facilitate downloadsto a workstation or mobile device [7] As such widgets aresimilar to web applications but are packaged for installation

Web browsers support a sandbox model of security isolatingeach web application from the device When a web applicationwants to break this sandbox it requires either an implicituser consent based on an action (eg file uploads throughclicking on a button and selecting a file) or explicit consentthrough some form of prompt (eg the geolocation API) Thisdecision may be remembered by the browser for subsequentrequests On most browsers saved explicit consent decisionscan be revoked through a settings page Web applications areidentified by origin ndash their DNS name port and protocol ndashand JavaScript on any one origin cannot (in general) accessany other Consent decisions however are often stored basedon hostname [8]

Widgets are run in a web runtime which is similar to abrowser Widgets are packaged as zip files containing (amongother things) a configuration file listing the APIs they requestaccess to These can be used as permission requests in asimilar manner to Android application manifests Widgets canbe identified by namespace and id attributes declared in theconfiguration file and widget packages can be signed by theirauthor Widgets are not restricted by the same origin policybut may use the Widget Access Request Policy instead [9]

B Mobile applications and access control

The most popular native mobile application systems areGoogle Android and iOS Android takes an lsquoall-or-nothingrsquoapproach to authorisation this involves developers specifyinga mandatory access control policy for APIs in the applicationmanifest [10] At install time users either agree to grant allrequested permissions or none at all On iOS applications aregranted access to the full system by default although usersare able to enable or disable access to geolocation data

The Android policy system has been criticised for beingineffective although recent results suggest that applicationpermissions are a valuable security mechanism [11] Severalattempts have been made to modify how policies are specifiedand used A common complaint is that Android permissionscannot be individually allowed or denied a feature providedby MockDroid [12] Apex [13] does the same as well assupporting controls such as limiting the number of times apermission may be used The CRePe system [14] allows thespecification of fine-grained context-dependent policies whichmay be based on time location and the originator of the policyCRePe also supports optional notification that a particularcontext has been activated Reddy et al [15] make the obser-vation that Android policies are resource-centric rather thanapplication-centric and that security would be better served ifapplications could request access just to common functionalitysuch as lsquoscan barcodersquo rather than the whole camera This isanalogous to program-language security features where onlycertain methods are made public to external callers FinallySEAndroid has been proposed to better sandbox applicationsconfine privileged daemon processes and provide a centralanalysable system policy [16]

C Bridging the gap web application security frameworks

Web applications and widgets require standardised APIs foraccessing device features and these are only slowly beingimplemented by browsers As a result several initiatives havebeen started to speed up standardisation and create cross-platform web application runtime environments These havealso included security frameworks

The BONDI security framework for web applications wascreated by OMTP a consortium of operators and handsetmanufacturers OMTP was eventually enlarged and renamedas the Wholesale Application Community (WAC) The WAC20 framework [17] combined BONDI with work by the W3CDevice APIs and Policy Working Group [3] BONDI usesXACML (eXtensible Access Control Markup Language) tospecify widget access control policies All widgets requestingaccess to WAC APIs are mediated by the XACML policyenforcement system XACML is a general-purpose access con-trol policy language based on subjects resources actions andconditions [18] XACML also defines a reference architecturefor policy control and enforcement as well as a messageschema To better situate XACML for a mobile environmentBONDI reduced the number of allowed expressions and spec-ified an appropriate dictionary

A problem with the WAC model is the role of the handsetuser as a policy authority Once an application has beengranted access to a certain device capability then it can usetransmit and share it without any further control or restrictionWork by the EU FP7 PrimeLife project [19] addressed thisissue by developing tools to protect user data and manageprivacy requirements these tools included a policy languagefor privacy and data protection based on XACML [20]

Finally the Chrome browser also supports up-front permis-sion requests by installable web applications (equivalent towidgets) downloaded from the Chrome Web Store Permis-sions are split into high medium and low-risk categories withAPIs for accessing geolocation and browser history markedas rsquolowrsquo Geolocation may also be requested at runtime inthe same manner as normal web pages The Chrome browsersupports synchronisation of settings between different deviceswhen the user has logged in with their Google user accountHowever the privacy and security implications of synchro-nising access control decisions and other data with a centralprovider such as Google are considerable Users may needassurance of the integrity and confidentiality of their cloud-based data [21] and may wish to chose a synchronising hostthat they trust This implies a need for standard cloud datapolicies to allow users to migrate between different providers

D Related literature

Mobile access control policies have been discussed exten-sively in academic literature although rarely in the contextof web applications In ubiquitous computing research Kimet al [22] have proposed an extended role-based accesscontrol model which can take into consideration changesin user context Roles are useful abstractions in workingenvironments but are perhaps less appropriate for personaldevices and ad-hoc collaborations Corradi et al [23] alsointroduce a context-based access control system and contextmodel Again however the focus is on pre-defined policies forcertain contexts rather than user-defined policies for personalresources Indeed user-defined policies for ad-hoc interactionsare arguably a more complicated problem Mazurek et al showthat in home environments people need fine-grained accesscontrol and want to be able to express policies requiring othersto ask before access to a resource is granted [24] Baldauf etal give a further survey of context-aware systems [25]

Several authors have suggested modifications to webbrowsers and their security model most of which aim tomitigate attacks by malicious web pages The Gazelle WebBrowser [26] aims to protect web applications (defined byorigin) from each other by separating them and their resourcesinto different OS-enforced protection domains This protectionalso applies to browser plugins The Tahoma Web BrowsingSystem [27] isolates websites by compartmentalising theminto virtual machines It makes web applications first-classobjects requiring them to be installed and approved beforefirst use Tahoma mediates all network interaction and requiresweb applications to have a widget-like manifest which defineany plugins that are required by the application Finally

Singh et al [28] introduce the notion of a user principle andsuggest that all access to certain APIs and actions (geolocationbrowsing history) should be considered owned by the user andaccess to them should therefore also be mediated by users

In native mobile applications the many improvements havebeen suggested to the Android permission system as discussedin section II-B In addition Ai et al [29] propose an alternativesynchronisation system for storing and recovering user data viaan online service If applied to permissions this might be away to implement cross-device policies However their focusis primarily on preventing the loss of user data rather thanmulti-device use cases

E Summary

Users are required to make access control decisions for bothnative and web applications The general principles are thesame in both cases ndash users must mediate access to potentiallysensitive resources ndash although the way in which permission isgranted differs However in both cases users end up makingdecisions out of context either at install time or first use andonly for one device at a time Existing systems which arecontext-aware tend to be aimed at users with one device aspart of larger organisations and systems such as Chrome allowsynchronisation but not context adaptation Yet context is evenmore important when policies are synchronised onersquos securityand privacy preferences when installing a mobile applicationat home may not be same as those associated with usingit outdoors Unfortunately designing access control policiesfor different device and contexts is easier said than doneand likely to become more complex for web applications asthey become more functionally capable and used on a widerrange of devices Furthermore additional scenarios involvingmultiple devices being used together at the same time andmultiple users interacting increase the need for a commonway of expressing access control policies

III CROSS-DEVICE AUTHORISATION

The state of the art described in the previous section mostlyfocused on one user with one mobile device This does notreflect how people use technology today they may rely onseveral devices in different contexts This section describesthe requirements for access control within a personal networkof devices and explains how the webinos architecture beginsto satisfy them

A Requirements for personal cross-device access control

Each user device can potentially run several web applica-tions each requiring access to local hardware capabilities aswell as functionality from other devices In combination withthe current state of the art described in the previous sectionwe have elicited the following requirements

1) Users and other stakeholders shall be able to controlaccess by web applications to JavaScript APIs TheseAPIs may allow access to local and remote resources

2) Users shall be able to create both device-specific anddevice-agnostic policies

3) The platform shall provide synchronization for accesscontrol policies so that policies can be described onone platform and enforced on all

4) The platform shall allow context-sensitive access controldecisions eg these may change depending on theenvironment

5) The platform shall protect user privacy access re-questors shall be able to qualify how they will usethe data they are requesting and users shall be able toexpress constraints about data disclosure

Existing browsers and systems such as WAC provide somesupport for requirement 1 and the Chrome browser supportslimited synchronisation to satisfy requirement 3 Context-aware middleware provides support for requirement 4 TheXACML language may be well suited to expressing policiesto satisfy requirement 2 and work by Ardagna et al [20]can adapt this to satisfy requirement 5 However the combi-nation of these requirements and the cross-device nature ofweb browsing provide motivation for the development of thewebinos platform

B The webinos platform

webinos is a cross-device application platform for mobileweb applications and widgets It provides applications with aset of APIs for accessing local resources such as sensors andcontacts as well as APIs for communication with other devicesand services The platform aims to create a seamless multi-device user experience through data synchronisation and aconsistent access control system webinos is supported on fourmain device domains PCs smartphones in-car systems andset-top boxes It was primarily aimed at people who use andown many web-enabled devices with an emphasis on personaland social computing More detailed personas of anticipatedusers are available in project deliverables [30] as are detaileduse cases and scenarios [31]

The platform was designed with the following high-levelgoals in mind

bull Interoperability of applications across the aforemen-tioned four device domains Each application can com-municate with others on the same device with anotherdevice belonging to the same user or with an unknowndevice elsewhere

bull Compatibility ndash achieved through standard JavaScriptAPIs This allows applications to run on multiple deviceswith minimal modification

bull Security and privacy for users and application develop-ers

bull Adaptability ndash allowing applications and devices to takeadvantage of information about the current environment

bull Usability ndash through the creation of a seamless experiencefor users of applications across multiple devices

C webinos lsquopersonal zonesrsquo of devices

The webinos platform aims to meet requirements 2-5 fromSection III-A by introducing the concept of a personal zonethe set of all devices owned by an end user It is an abstraction

Fig 1 Overview of the webinos personal zone model

which provides a basis for managing devices together withthe services running on them From the web applicationperspective all devices in the zone support and expose a set ofstandard APIs for accessing services such as device features(cameras geolocation) networking with other devices andcloud services

Personal zones contain three key components the webruntime proxy and hub The Web Runtime is where webapplications are executed The runtime has been extended toprovide a set of JavaScript APIs which allow applications tojoin a personal zone communicate with other devices andaccess features These API requests are forwarded to thepersonal zone proxy

The Personal Zone Proxy (PZP) implements the APIsand provides the communication layer with other devices Itcommunicates with the hub through a mutually authenticatedTLS session and communicates peer-to-peer with other proxieswhere internet connectivity is unavailable Each proxy has itsown policy enforcement and decision point

The Personal Zone Hub (PZH) runs on a web server whichmay be hosted by a third party or be part of a userrsquos homenetworking equipment It is the central point of access to thezone so that each device can contact others and request accessto resources and services The hub is a repository for synchro-nized data and policies and provides policy enforcement forincoming requests The hub enrols each PZP into the zone byissuing it with a certificate

The relationship between these components can be seen inFigure 1

As an example suppose that Alice is using her smartphoneand wants to access a media file on her PC She loads hermedia player web application which requests access to thefile via a JavaScript API provided by the webinos web runtimeextension on her smartphone The runtime extension passes therequest to the PZP which passes the request to the web-basedPZH The hub then forwards this to the PZP on Alicersquos PCwhich contains the implementation of the File API The fileis then transferred through the hub back to the media playerapplication on the smartphone

IV THE webinos POLICY FRAMEWORK

A Basic architectureThe webinos platform provides privacy protection and ac-

cess control features to meet the privacy and security require-ments of web applications and users This means protectingagainst malware and other users who may attempt to accessmore data than they should or simply avoiding the unnecessarydisclosure of personal data To satisfy these requirementswebinos relies on the strong identification of web applicationsusers and devices combined with a least-privilege accesscontrol based on XACML

However while the latest version of XACML introduceda privacy profile specifying two purpose attributes [32] it isstill not well suited for describing data handling policies Forthis reason the XACML architecture has been adapted usingPrimeLife extensions [33] allowing webinos to make accesscontrol decisions based on both the request context and userpreferences

The object model depicted in Figure 2 shows the main com-ponents of the webinos policy framework Both the PZP andPZH enforce policies using standard XACML componentssupplemented by

bull The Decision Wrapper creates the initial policy enforce-ment query based on incoming requests

bull The Access Manager makes the final decision by com-bining XACML access control and DHDF data

bull The Data Handling Decision Function (DHDF) engineprovides privacy and data handling functionalities

bull The Request Context manages all contextual informationit stores all the data and credentials released by a user ina given session

bull The PDP Cache (PDPC) stores PDP decisions that couldbe share among personal devices

PIP

Context Handler

PAP PDPC

PZP

PDP

Data Reader

Request Context

Credential System

Obligations

PEP

DHDF Engine

Access Manager

Decision Wrapper

PZP PZH

Access Requestor

RemoteAccess

Requestor

Overlay Network

PZrsquos copy ofPAP PDPC PIP

Fig 2 Components of the webinos policy framework on a device Requestscome from either local or remote sources and are then managed by theDecision Wrapper Policies are held on a PZP and may depend on data fetchedfrom the rest of the personal zone

B Adapting the state of the artPolicies are expressed in a similar way to the format defined

in BONDI [34] However BONDI policies do not support

cross-device interaction The webinos framework thereforemodifies the subject of policies to refer to the device and userPolicies are also able to refer to a dynamically changing setof features as new APIs may be added by new applicationswebinos policies are usually composed in the following waywhere device T is the target device and device R is therequesting device

User U can access Feature F of Device T through applica-tion A on Device R

Figures 3 and 4 show an application requesting access toa remote device feature Every subject (user application anddevice) has an id used to determine if a specific policy shouldbe taken in account when enforcing incoming requests Toperform this selection the Policy Manager tries to match therequestrsquos information against policy targets

ContextPolicies

PolicyEnforcement

TR

U

A 1 Request Position

4 Position

2 Can T return Geolocationrsquos data to

R

3 YES

Fig 3 Example of a request to access a remote devicersquos features ApplicationA launched by user U in set-top box R requires access to geolocation dataprovided by car T

ContextPolicies

PolicyEnforcement

Reply

RequestorDevice

TargetDevice

RequestedAPI

Requestrsquos Info

Request

APP

Fig 4 Every application that requires to access a feature sends a requestwhich is filled with information on the subjects and requested feature

Special URIs are used as ids in policies to match subjectsand services Whenever an entity (user device application orservice) is registered for the first time a record with somebasic identity information is stored These records are used toconvert a generic ID into a convenient URI

There are four basic types of information in the policyrsquossubject The user identified by the URI of their PZH Therequesting device as identified by the TLS certificate issued toeach device when it enrols in a personal zone omitting this in apolicy allows it to apply to applications running on any deviceThe target device similarly identified omitting this allows forpolicies which refer to an API on all devices eg denyingany access to location data Finally the application ID author

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

tation of webinos a cross-device web application platformwebinos is designed to give web developers access to astandard set of APIs for device features as well as providing acommon policy model for access control It also aims to giveusers a lsquoseamlessrsquo experience by providing better connectivitybetween devices The platform is targeted at four domains PCmobile in-car and smart TVs We have developed an XACML-based system which provides a single policy enforcementmechanism for a userrsquos personal zone ndash the devices theyown and use Our main contributions are the introductionof a personal zone architecture the definition of a modifiedXACML policy system to support this abstraction on alldevices and several observations from design experience

We begin in Section II by discussing the state of the artin access control and policy enforcement for mobile webapplications and web widgets In Section III we describethe requirements for a personal cross-device authorisationsystem and give an introduction to the webinos personalzone model Following this Section IV describes the webinospolicy framework and section V covers four of the conceptualchallenges faced during design and development Finally insection VI we conclude

II BACKGROUND

A Web applications widgets and browser security

A web application in a mobile context is a web page orcollection of web pages delivered over HTTP which usesserver or client-side processing to produce an application-like experience within a web browser [6] In comparisonweb widgets are interactive applications for displaying andorupdating local or remote data packaged to facilitate downloadsto a workstation or mobile device [7] As such widgets aresimilar to web applications but are packaged for installation

Web browsers support a sandbox model of security isolatingeach web application from the device When a web applicationwants to break this sandbox it requires either an implicituser consent based on an action (eg file uploads throughclicking on a button and selecting a file) or explicit consentthrough some form of prompt (eg the geolocation API) Thisdecision may be remembered by the browser for subsequentrequests On most browsers saved explicit consent decisionscan be revoked through a settings page Web applications areidentified by origin ndash their DNS name port and protocol ndashand JavaScript on any one origin cannot (in general) accessany other Consent decisions however are often stored basedon hostname [8]

Widgets are run in a web runtime which is similar to abrowser Widgets are packaged as zip files containing (amongother things) a configuration file listing the APIs they requestaccess to These can be used as permission requests in asimilar manner to Android application manifests Widgets canbe identified by namespace and id attributes declared in theconfiguration file and widget packages can be signed by theirauthor Widgets are not restricted by the same origin policybut may use the Widget Access Request Policy instead [9]

B Mobile applications and access control

The most popular native mobile application systems areGoogle Android and iOS Android takes an lsquoall-or-nothingrsquoapproach to authorisation this involves developers specifyinga mandatory access control policy for APIs in the applicationmanifest [10] At install time users either agree to grant allrequested permissions or none at all On iOS applications aregranted access to the full system by default although usersare able to enable or disable access to geolocation data

The Android policy system has been criticised for beingineffective although recent results suggest that applicationpermissions are a valuable security mechanism [11] Severalattempts have been made to modify how policies are specifiedand used A common complaint is that Android permissionscannot be individually allowed or denied a feature providedby MockDroid [12] Apex [13] does the same as well assupporting controls such as limiting the number of times apermission may be used The CRePe system [14] allows thespecification of fine-grained context-dependent policies whichmay be based on time location and the originator of the policyCRePe also supports optional notification that a particularcontext has been activated Reddy et al [15] make the obser-vation that Android policies are resource-centric rather thanapplication-centric and that security would be better served ifapplications could request access just to common functionalitysuch as lsquoscan barcodersquo rather than the whole camera This isanalogous to program-language security features where onlycertain methods are made public to external callers FinallySEAndroid has been proposed to better sandbox applicationsconfine privileged daemon processes and provide a centralanalysable system policy [16]

C Bridging the gap web application security frameworks

Web applications and widgets require standardised APIs foraccessing device features and these are only slowly beingimplemented by browsers As a result several initiatives havebeen started to speed up standardisation and create cross-platform web application runtime environments These havealso included security frameworks

The BONDI security framework for web applications wascreated by OMTP a consortium of operators and handsetmanufacturers OMTP was eventually enlarged and renamedas the Wholesale Application Community (WAC) The WAC20 framework [17] combined BONDI with work by the W3CDevice APIs and Policy Working Group [3] BONDI usesXACML (eXtensible Access Control Markup Language) tospecify widget access control policies All widgets requestingaccess to WAC APIs are mediated by the XACML policyenforcement system XACML is a general-purpose access con-trol policy language based on subjects resources actions andconditions [18] XACML also defines a reference architecturefor policy control and enforcement as well as a messageschema To better situate XACML for a mobile environmentBONDI reduced the number of allowed expressions and spec-ified an appropriate dictionary

A problem with the WAC model is the role of the handsetuser as a policy authority Once an application has beengranted access to a certain device capability then it can usetransmit and share it without any further control or restrictionWork by the EU FP7 PrimeLife project [19] addressed thisissue by developing tools to protect user data and manageprivacy requirements these tools included a policy languagefor privacy and data protection based on XACML [20]

Finally the Chrome browser also supports up-front permis-sion requests by installable web applications (equivalent towidgets) downloaded from the Chrome Web Store Permis-sions are split into high medium and low-risk categories withAPIs for accessing geolocation and browser history markedas rsquolowrsquo Geolocation may also be requested at runtime inthe same manner as normal web pages The Chrome browsersupports synchronisation of settings between different deviceswhen the user has logged in with their Google user accountHowever the privacy and security implications of synchro-nising access control decisions and other data with a centralprovider such as Google are considerable Users may needassurance of the integrity and confidentiality of their cloud-based data [21] and may wish to chose a synchronising hostthat they trust This implies a need for standard cloud datapolicies to allow users to migrate between different providers

D Related literature

Mobile access control policies have been discussed exten-sively in academic literature although rarely in the contextof web applications In ubiquitous computing research Kimet al [22] have proposed an extended role-based accesscontrol model which can take into consideration changesin user context Roles are useful abstractions in workingenvironments but are perhaps less appropriate for personaldevices and ad-hoc collaborations Corradi et al [23] alsointroduce a context-based access control system and contextmodel Again however the focus is on pre-defined policies forcertain contexts rather than user-defined policies for personalresources Indeed user-defined policies for ad-hoc interactionsare arguably a more complicated problem Mazurek et al showthat in home environments people need fine-grained accesscontrol and want to be able to express policies requiring othersto ask before access to a resource is granted [24] Baldauf etal give a further survey of context-aware systems [25]

Several authors have suggested modifications to webbrowsers and their security model most of which aim tomitigate attacks by malicious web pages The Gazelle WebBrowser [26] aims to protect web applications (defined byorigin) from each other by separating them and their resourcesinto different OS-enforced protection domains This protectionalso applies to browser plugins The Tahoma Web BrowsingSystem [27] isolates websites by compartmentalising theminto virtual machines It makes web applications first-classobjects requiring them to be installed and approved beforefirst use Tahoma mediates all network interaction and requiresweb applications to have a widget-like manifest which defineany plugins that are required by the application Finally

Singh et al [28] introduce the notion of a user principle andsuggest that all access to certain APIs and actions (geolocationbrowsing history) should be considered owned by the user andaccess to them should therefore also be mediated by users

In native mobile applications the many improvements havebeen suggested to the Android permission system as discussedin section II-B In addition Ai et al [29] propose an alternativesynchronisation system for storing and recovering user data viaan online service If applied to permissions this might be away to implement cross-device policies However their focusis primarily on preventing the loss of user data rather thanmulti-device use cases

E Summary

Users are required to make access control decisions for bothnative and web applications The general principles are thesame in both cases ndash users must mediate access to potentiallysensitive resources ndash although the way in which permission isgranted differs However in both cases users end up makingdecisions out of context either at install time or first use andonly for one device at a time Existing systems which arecontext-aware tend to be aimed at users with one device aspart of larger organisations and systems such as Chrome allowsynchronisation but not context adaptation Yet context is evenmore important when policies are synchronised onersquos securityand privacy preferences when installing a mobile applicationat home may not be same as those associated with usingit outdoors Unfortunately designing access control policiesfor different device and contexts is easier said than doneand likely to become more complex for web applications asthey become more functionally capable and used on a widerrange of devices Furthermore additional scenarios involvingmultiple devices being used together at the same time andmultiple users interacting increase the need for a commonway of expressing access control policies

III CROSS-DEVICE AUTHORISATION

The state of the art described in the previous section mostlyfocused on one user with one mobile device This does notreflect how people use technology today they may rely onseveral devices in different contexts This section describesthe requirements for access control within a personal networkof devices and explains how the webinos architecture beginsto satisfy them

A Requirements for personal cross-device access control

Each user device can potentially run several web applica-tions each requiring access to local hardware capabilities aswell as functionality from other devices In combination withthe current state of the art described in the previous sectionwe have elicited the following requirements

1) Users and other stakeholders shall be able to controlaccess by web applications to JavaScript APIs TheseAPIs may allow access to local and remote resources

2) Users shall be able to create both device-specific anddevice-agnostic policies

3) The platform shall provide synchronization for accesscontrol policies so that policies can be described onone platform and enforced on all

4) The platform shall allow context-sensitive access controldecisions eg these may change depending on theenvironment

5) The platform shall protect user privacy access re-questors shall be able to qualify how they will usethe data they are requesting and users shall be able toexpress constraints about data disclosure

Existing browsers and systems such as WAC provide somesupport for requirement 1 and the Chrome browser supportslimited synchronisation to satisfy requirement 3 Context-aware middleware provides support for requirement 4 TheXACML language may be well suited to expressing policiesto satisfy requirement 2 and work by Ardagna et al [20]can adapt this to satisfy requirement 5 However the combi-nation of these requirements and the cross-device nature ofweb browsing provide motivation for the development of thewebinos platform

B The webinos platform

webinos is a cross-device application platform for mobileweb applications and widgets It provides applications with aset of APIs for accessing local resources such as sensors andcontacts as well as APIs for communication with other devicesand services The platform aims to create a seamless multi-device user experience through data synchronisation and aconsistent access control system webinos is supported on fourmain device domains PCs smartphones in-car systems andset-top boxes It was primarily aimed at people who use andown many web-enabled devices with an emphasis on personaland social computing More detailed personas of anticipatedusers are available in project deliverables [30] as are detaileduse cases and scenarios [31]

The platform was designed with the following high-levelgoals in mind

bull Interoperability of applications across the aforemen-tioned four device domains Each application can com-municate with others on the same device with anotherdevice belonging to the same user or with an unknowndevice elsewhere

bull Compatibility ndash achieved through standard JavaScriptAPIs This allows applications to run on multiple deviceswith minimal modification

bull Security and privacy for users and application develop-ers

bull Adaptability ndash allowing applications and devices to takeadvantage of information about the current environment

bull Usability ndash through the creation of a seamless experiencefor users of applications across multiple devices

C webinos lsquopersonal zonesrsquo of devices

The webinos platform aims to meet requirements 2-5 fromSection III-A by introducing the concept of a personal zonethe set of all devices owned by an end user It is an abstraction

Fig 1 Overview of the webinos personal zone model

which provides a basis for managing devices together withthe services running on them From the web applicationperspective all devices in the zone support and expose a set ofstandard APIs for accessing services such as device features(cameras geolocation) networking with other devices andcloud services

Personal zones contain three key components the webruntime proxy and hub The Web Runtime is where webapplications are executed The runtime has been extended toprovide a set of JavaScript APIs which allow applications tojoin a personal zone communicate with other devices andaccess features These API requests are forwarded to thepersonal zone proxy

The Personal Zone Proxy (PZP) implements the APIsand provides the communication layer with other devices Itcommunicates with the hub through a mutually authenticatedTLS session and communicates peer-to-peer with other proxieswhere internet connectivity is unavailable Each proxy has itsown policy enforcement and decision point

The Personal Zone Hub (PZH) runs on a web server whichmay be hosted by a third party or be part of a userrsquos homenetworking equipment It is the central point of access to thezone so that each device can contact others and request accessto resources and services The hub is a repository for synchro-nized data and policies and provides policy enforcement forincoming requests The hub enrols each PZP into the zone byissuing it with a certificate

The relationship between these components can be seen inFigure 1

As an example suppose that Alice is using her smartphoneand wants to access a media file on her PC She loads hermedia player web application which requests access to thefile via a JavaScript API provided by the webinos web runtimeextension on her smartphone The runtime extension passes therequest to the PZP which passes the request to the web-basedPZH The hub then forwards this to the PZP on Alicersquos PCwhich contains the implementation of the File API The fileis then transferred through the hub back to the media playerapplication on the smartphone

IV THE webinos POLICY FRAMEWORK

A Basic architectureThe webinos platform provides privacy protection and ac-

cess control features to meet the privacy and security require-ments of web applications and users This means protectingagainst malware and other users who may attempt to accessmore data than they should or simply avoiding the unnecessarydisclosure of personal data To satisfy these requirementswebinos relies on the strong identification of web applicationsusers and devices combined with a least-privilege accesscontrol based on XACML

However while the latest version of XACML introduceda privacy profile specifying two purpose attributes [32] it isstill not well suited for describing data handling policies Forthis reason the XACML architecture has been adapted usingPrimeLife extensions [33] allowing webinos to make accesscontrol decisions based on both the request context and userpreferences

The object model depicted in Figure 2 shows the main com-ponents of the webinos policy framework Both the PZP andPZH enforce policies using standard XACML componentssupplemented by

bull The Decision Wrapper creates the initial policy enforce-ment query based on incoming requests

bull The Access Manager makes the final decision by com-bining XACML access control and DHDF data

bull The Data Handling Decision Function (DHDF) engineprovides privacy and data handling functionalities

bull The Request Context manages all contextual informationit stores all the data and credentials released by a user ina given session

bull The PDP Cache (PDPC) stores PDP decisions that couldbe share among personal devices

PIP

Context Handler

PAP PDPC

PZP

PDP

Data Reader

Request Context

Credential System

Obligations

PEP

DHDF Engine

Access Manager

Decision Wrapper

PZP PZH

Access Requestor

RemoteAccess

Requestor

Overlay Network

PZrsquos copy ofPAP PDPC PIP

Fig 2 Components of the webinos policy framework on a device Requestscome from either local or remote sources and are then managed by theDecision Wrapper Policies are held on a PZP and may depend on data fetchedfrom the rest of the personal zone

B Adapting the state of the artPolicies are expressed in a similar way to the format defined

in BONDI [34] However BONDI policies do not support

cross-device interaction The webinos framework thereforemodifies the subject of policies to refer to the device and userPolicies are also able to refer to a dynamically changing setof features as new APIs may be added by new applicationswebinos policies are usually composed in the following waywhere device T is the target device and device R is therequesting device

User U can access Feature F of Device T through applica-tion A on Device R

Figures 3 and 4 show an application requesting access toa remote device feature Every subject (user application anddevice) has an id used to determine if a specific policy shouldbe taken in account when enforcing incoming requests Toperform this selection the Policy Manager tries to match therequestrsquos information against policy targets

ContextPolicies

PolicyEnforcement

TR

U

A 1 Request Position

4 Position

2 Can T return Geolocationrsquos data to

R

3 YES

Fig 3 Example of a request to access a remote devicersquos features ApplicationA launched by user U in set-top box R requires access to geolocation dataprovided by car T

ContextPolicies

PolicyEnforcement

Reply

RequestorDevice

TargetDevice

RequestedAPI

Requestrsquos Info

Request

APP

Fig 4 Every application that requires to access a feature sends a requestwhich is filled with information on the subjects and requested feature

Special URIs are used as ids in policies to match subjectsand services Whenever an entity (user device application orservice) is registered for the first time a record with somebasic identity information is stored These records are used toconvert a generic ID into a convenient URI

There are four basic types of information in the policyrsquossubject The user identified by the URI of their PZH Therequesting device as identified by the TLS certificate issued toeach device when it enrols in a personal zone omitting this in apolicy allows it to apply to applications running on any deviceThe target device similarly identified omitting this allows forpolicies which refer to an API on all devices eg denyingany access to location data Finally the application ID author

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

A problem with the WAC model is the role of the handsetuser as a policy authority Once an application has beengranted access to a certain device capability then it can usetransmit and share it without any further control or restrictionWork by the EU FP7 PrimeLife project [19] addressed thisissue by developing tools to protect user data and manageprivacy requirements these tools included a policy languagefor privacy and data protection based on XACML [20]

Finally the Chrome browser also supports up-front permis-sion requests by installable web applications (equivalent towidgets) downloaded from the Chrome Web Store Permis-sions are split into high medium and low-risk categories withAPIs for accessing geolocation and browser history markedas rsquolowrsquo Geolocation may also be requested at runtime inthe same manner as normal web pages The Chrome browsersupports synchronisation of settings between different deviceswhen the user has logged in with their Google user accountHowever the privacy and security implications of synchro-nising access control decisions and other data with a centralprovider such as Google are considerable Users may needassurance of the integrity and confidentiality of their cloud-based data [21] and may wish to chose a synchronising hostthat they trust This implies a need for standard cloud datapolicies to allow users to migrate between different providers

D Related literature

Mobile access control policies have been discussed exten-sively in academic literature although rarely in the contextof web applications In ubiquitous computing research Kimet al [22] have proposed an extended role-based accesscontrol model which can take into consideration changesin user context Roles are useful abstractions in workingenvironments but are perhaps less appropriate for personaldevices and ad-hoc collaborations Corradi et al [23] alsointroduce a context-based access control system and contextmodel Again however the focus is on pre-defined policies forcertain contexts rather than user-defined policies for personalresources Indeed user-defined policies for ad-hoc interactionsare arguably a more complicated problem Mazurek et al showthat in home environments people need fine-grained accesscontrol and want to be able to express policies requiring othersto ask before access to a resource is granted [24] Baldauf etal give a further survey of context-aware systems [25]

Several authors have suggested modifications to webbrowsers and their security model most of which aim tomitigate attacks by malicious web pages The Gazelle WebBrowser [26] aims to protect web applications (defined byorigin) from each other by separating them and their resourcesinto different OS-enforced protection domains This protectionalso applies to browser plugins The Tahoma Web BrowsingSystem [27] isolates websites by compartmentalising theminto virtual machines It makes web applications first-classobjects requiring them to be installed and approved beforefirst use Tahoma mediates all network interaction and requiresweb applications to have a widget-like manifest which defineany plugins that are required by the application Finally

Singh et al [28] introduce the notion of a user principle andsuggest that all access to certain APIs and actions (geolocationbrowsing history) should be considered owned by the user andaccess to them should therefore also be mediated by users

In native mobile applications the many improvements havebeen suggested to the Android permission system as discussedin section II-B In addition Ai et al [29] propose an alternativesynchronisation system for storing and recovering user data viaan online service If applied to permissions this might be away to implement cross-device policies However their focusis primarily on preventing the loss of user data rather thanmulti-device use cases

E Summary

Users are required to make access control decisions for bothnative and web applications The general principles are thesame in both cases ndash users must mediate access to potentiallysensitive resources ndash although the way in which permission isgranted differs However in both cases users end up makingdecisions out of context either at install time or first use andonly for one device at a time Existing systems which arecontext-aware tend to be aimed at users with one device aspart of larger organisations and systems such as Chrome allowsynchronisation but not context adaptation Yet context is evenmore important when policies are synchronised onersquos securityand privacy preferences when installing a mobile applicationat home may not be same as those associated with usingit outdoors Unfortunately designing access control policiesfor different device and contexts is easier said than doneand likely to become more complex for web applications asthey become more functionally capable and used on a widerrange of devices Furthermore additional scenarios involvingmultiple devices being used together at the same time andmultiple users interacting increase the need for a commonway of expressing access control policies

III CROSS-DEVICE AUTHORISATION

The state of the art described in the previous section mostlyfocused on one user with one mobile device This does notreflect how people use technology today they may rely onseveral devices in different contexts This section describesthe requirements for access control within a personal networkof devices and explains how the webinos architecture beginsto satisfy them

A Requirements for personal cross-device access control

Each user device can potentially run several web applica-tions each requiring access to local hardware capabilities aswell as functionality from other devices In combination withthe current state of the art described in the previous sectionwe have elicited the following requirements

1) Users and other stakeholders shall be able to controlaccess by web applications to JavaScript APIs TheseAPIs may allow access to local and remote resources

2) Users shall be able to create both device-specific anddevice-agnostic policies

3) The platform shall provide synchronization for accesscontrol policies so that policies can be described onone platform and enforced on all

4) The platform shall allow context-sensitive access controldecisions eg these may change depending on theenvironment

5) The platform shall protect user privacy access re-questors shall be able to qualify how they will usethe data they are requesting and users shall be able toexpress constraints about data disclosure

Existing browsers and systems such as WAC provide somesupport for requirement 1 and the Chrome browser supportslimited synchronisation to satisfy requirement 3 Context-aware middleware provides support for requirement 4 TheXACML language may be well suited to expressing policiesto satisfy requirement 2 and work by Ardagna et al [20]can adapt this to satisfy requirement 5 However the combi-nation of these requirements and the cross-device nature ofweb browsing provide motivation for the development of thewebinos platform

B The webinos platform

webinos is a cross-device application platform for mobileweb applications and widgets It provides applications with aset of APIs for accessing local resources such as sensors andcontacts as well as APIs for communication with other devicesand services The platform aims to create a seamless multi-device user experience through data synchronisation and aconsistent access control system webinos is supported on fourmain device domains PCs smartphones in-car systems andset-top boxes It was primarily aimed at people who use andown many web-enabled devices with an emphasis on personaland social computing More detailed personas of anticipatedusers are available in project deliverables [30] as are detaileduse cases and scenarios [31]

The platform was designed with the following high-levelgoals in mind

bull Interoperability of applications across the aforemen-tioned four device domains Each application can com-municate with others on the same device with anotherdevice belonging to the same user or with an unknowndevice elsewhere

bull Compatibility ndash achieved through standard JavaScriptAPIs This allows applications to run on multiple deviceswith minimal modification

bull Security and privacy for users and application develop-ers

bull Adaptability ndash allowing applications and devices to takeadvantage of information about the current environment

bull Usability ndash through the creation of a seamless experiencefor users of applications across multiple devices

C webinos lsquopersonal zonesrsquo of devices

The webinos platform aims to meet requirements 2-5 fromSection III-A by introducing the concept of a personal zonethe set of all devices owned by an end user It is an abstraction

Fig 1 Overview of the webinos personal zone model

which provides a basis for managing devices together withthe services running on them From the web applicationperspective all devices in the zone support and expose a set ofstandard APIs for accessing services such as device features(cameras geolocation) networking with other devices andcloud services

Personal zones contain three key components the webruntime proxy and hub The Web Runtime is where webapplications are executed The runtime has been extended toprovide a set of JavaScript APIs which allow applications tojoin a personal zone communicate with other devices andaccess features These API requests are forwarded to thepersonal zone proxy

The Personal Zone Proxy (PZP) implements the APIsand provides the communication layer with other devices Itcommunicates with the hub through a mutually authenticatedTLS session and communicates peer-to-peer with other proxieswhere internet connectivity is unavailable Each proxy has itsown policy enforcement and decision point

The Personal Zone Hub (PZH) runs on a web server whichmay be hosted by a third party or be part of a userrsquos homenetworking equipment It is the central point of access to thezone so that each device can contact others and request accessto resources and services The hub is a repository for synchro-nized data and policies and provides policy enforcement forincoming requests The hub enrols each PZP into the zone byissuing it with a certificate

The relationship between these components can be seen inFigure 1

As an example suppose that Alice is using her smartphoneand wants to access a media file on her PC She loads hermedia player web application which requests access to thefile via a JavaScript API provided by the webinos web runtimeextension on her smartphone The runtime extension passes therequest to the PZP which passes the request to the web-basedPZH The hub then forwards this to the PZP on Alicersquos PCwhich contains the implementation of the File API The fileis then transferred through the hub back to the media playerapplication on the smartphone

IV THE webinos POLICY FRAMEWORK

A Basic architectureThe webinos platform provides privacy protection and ac-

cess control features to meet the privacy and security require-ments of web applications and users This means protectingagainst malware and other users who may attempt to accessmore data than they should or simply avoiding the unnecessarydisclosure of personal data To satisfy these requirementswebinos relies on the strong identification of web applicationsusers and devices combined with a least-privilege accesscontrol based on XACML

However while the latest version of XACML introduceda privacy profile specifying two purpose attributes [32] it isstill not well suited for describing data handling policies Forthis reason the XACML architecture has been adapted usingPrimeLife extensions [33] allowing webinos to make accesscontrol decisions based on both the request context and userpreferences

The object model depicted in Figure 2 shows the main com-ponents of the webinos policy framework Both the PZP andPZH enforce policies using standard XACML componentssupplemented by

bull The Decision Wrapper creates the initial policy enforce-ment query based on incoming requests

bull The Access Manager makes the final decision by com-bining XACML access control and DHDF data

bull The Data Handling Decision Function (DHDF) engineprovides privacy and data handling functionalities

bull The Request Context manages all contextual informationit stores all the data and credentials released by a user ina given session

bull The PDP Cache (PDPC) stores PDP decisions that couldbe share among personal devices

PIP

Context Handler

PAP PDPC

PZP

PDP

Data Reader

Request Context

Credential System

Obligations

PEP

DHDF Engine

Access Manager

Decision Wrapper

PZP PZH

Access Requestor

RemoteAccess

Requestor

Overlay Network

PZrsquos copy ofPAP PDPC PIP

Fig 2 Components of the webinos policy framework on a device Requestscome from either local or remote sources and are then managed by theDecision Wrapper Policies are held on a PZP and may depend on data fetchedfrom the rest of the personal zone

B Adapting the state of the artPolicies are expressed in a similar way to the format defined

in BONDI [34] However BONDI policies do not support

cross-device interaction The webinos framework thereforemodifies the subject of policies to refer to the device and userPolicies are also able to refer to a dynamically changing setof features as new APIs may be added by new applicationswebinos policies are usually composed in the following waywhere device T is the target device and device R is therequesting device

User U can access Feature F of Device T through applica-tion A on Device R

Figures 3 and 4 show an application requesting access toa remote device feature Every subject (user application anddevice) has an id used to determine if a specific policy shouldbe taken in account when enforcing incoming requests Toperform this selection the Policy Manager tries to match therequestrsquos information against policy targets

ContextPolicies

PolicyEnforcement

TR

U

A 1 Request Position

4 Position

2 Can T return Geolocationrsquos data to

R

3 YES

Fig 3 Example of a request to access a remote devicersquos features ApplicationA launched by user U in set-top box R requires access to geolocation dataprovided by car T

ContextPolicies

PolicyEnforcement

Reply

RequestorDevice

TargetDevice

RequestedAPI

Requestrsquos Info

Request

APP

Fig 4 Every application that requires to access a feature sends a requestwhich is filled with information on the subjects and requested feature

Special URIs are used as ids in policies to match subjectsand services Whenever an entity (user device application orservice) is registered for the first time a record with somebasic identity information is stored These records are used toconvert a generic ID into a convenient URI

There are four basic types of information in the policyrsquossubject The user identified by the URI of their PZH Therequesting device as identified by the TLS certificate issued toeach device when it enrols in a personal zone omitting this in apolicy allows it to apply to applications running on any deviceThe target device similarly identified omitting this allows forpolicies which refer to an API on all devices eg denyingany access to location data Finally the application ID author

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

3) The platform shall provide synchronization for accesscontrol policies so that policies can be described onone platform and enforced on all

4) The platform shall allow context-sensitive access controldecisions eg these may change depending on theenvironment

5) The platform shall protect user privacy access re-questors shall be able to qualify how they will usethe data they are requesting and users shall be able toexpress constraints about data disclosure

Existing browsers and systems such as WAC provide somesupport for requirement 1 and the Chrome browser supportslimited synchronisation to satisfy requirement 3 Context-aware middleware provides support for requirement 4 TheXACML language may be well suited to expressing policiesto satisfy requirement 2 and work by Ardagna et al [20]can adapt this to satisfy requirement 5 However the combi-nation of these requirements and the cross-device nature ofweb browsing provide motivation for the development of thewebinos platform

B The webinos platform

webinos is a cross-device application platform for mobileweb applications and widgets It provides applications with aset of APIs for accessing local resources such as sensors andcontacts as well as APIs for communication with other devicesand services The platform aims to create a seamless multi-device user experience through data synchronisation and aconsistent access control system webinos is supported on fourmain device domains PCs smartphones in-car systems andset-top boxes It was primarily aimed at people who use andown many web-enabled devices with an emphasis on personaland social computing More detailed personas of anticipatedusers are available in project deliverables [30] as are detaileduse cases and scenarios [31]

The platform was designed with the following high-levelgoals in mind

bull Interoperability of applications across the aforemen-tioned four device domains Each application can com-municate with others on the same device with anotherdevice belonging to the same user or with an unknowndevice elsewhere

bull Compatibility ndash achieved through standard JavaScriptAPIs This allows applications to run on multiple deviceswith minimal modification

bull Security and privacy for users and application develop-ers

bull Adaptability ndash allowing applications and devices to takeadvantage of information about the current environment

bull Usability ndash through the creation of a seamless experiencefor users of applications across multiple devices

C webinos lsquopersonal zonesrsquo of devices

The webinos platform aims to meet requirements 2-5 fromSection III-A by introducing the concept of a personal zonethe set of all devices owned by an end user It is an abstraction

Fig 1 Overview of the webinos personal zone model

which provides a basis for managing devices together withthe services running on them From the web applicationperspective all devices in the zone support and expose a set ofstandard APIs for accessing services such as device features(cameras geolocation) networking with other devices andcloud services

Personal zones contain three key components the webruntime proxy and hub The Web Runtime is where webapplications are executed The runtime has been extended toprovide a set of JavaScript APIs which allow applications tojoin a personal zone communicate with other devices andaccess features These API requests are forwarded to thepersonal zone proxy

The Personal Zone Proxy (PZP) implements the APIsand provides the communication layer with other devices Itcommunicates with the hub through a mutually authenticatedTLS session and communicates peer-to-peer with other proxieswhere internet connectivity is unavailable Each proxy has itsown policy enforcement and decision point

The Personal Zone Hub (PZH) runs on a web server whichmay be hosted by a third party or be part of a userrsquos homenetworking equipment It is the central point of access to thezone so that each device can contact others and request accessto resources and services The hub is a repository for synchro-nized data and policies and provides policy enforcement forincoming requests The hub enrols each PZP into the zone byissuing it with a certificate

The relationship between these components can be seen inFigure 1

As an example suppose that Alice is using her smartphoneand wants to access a media file on her PC She loads hermedia player web application which requests access to thefile via a JavaScript API provided by the webinos web runtimeextension on her smartphone The runtime extension passes therequest to the PZP which passes the request to the web-basedPZH The hub then forwards this to the PZP on Alicersquos PCwhich contains the implementation of the File API The fileis then transferred through the hub back to the media playerapplication on the smartphone

IV THE webinos POLICY FRAMEWORK

A Basic architectureThe webinos platform provides privacy protection and ac-

cess control features to meet the privacy and security require-ments of web applications and users This means protectingagainst malware and other users who may attempt to accessmore data than they should or simply avoiding the unnecessarydisclosure of personal data To satisfy these requirementswebinos relies on the strong identification of web applicationsusers and devices combined with a least-privilege accesscontrol based on XACML

However while the latest version of XACML introduceda privacy profile specifying two purpose attributes [32] it isstill not well suited for describing data handling policies Forthis reason the XACML architecture has been adapted usingPrimeLife extensions [33] allowing webinos to make accesscontrol decisions based on both the request context and userpreferences

The object model depicted in Figure 2 shows the main com-ponents of the webinos policy framework Both the PZP andPZH enforce policies using standard XACML componentssupplemented by

bull The Decision Wrapper creates the initial policy enforce-ment query based on incoming requests

bull The Access Manager makes the final decision by com-bining XACML access control and DHDF data

bull The Data Handling Decision Function (DHDF) engineprovides privacy and data handling functionalities

bull The Request Context manages all contextual informationit stores all the data and credentials released by a user ina given session

bull The PDP Cache (PDPC) stores PDP decisions that couldbe share among personal devices

PIP

Context Handler

PAP PDPC

PZP

PDP

Data Reader

Request Context

Credential System

Obligations

PEP

DHDF Engine

Access Manager

Decision Wrapper

PZP PZH

Access Requestor

RemoteAccess

Requestor

Overlay Network

PZrsquos copy ofPAP PDPC PIP

Fig 2 Components of the webinos policy framework on a device Requestscome from either local or remote sources and are then managed by theDecision Wrapper Policies are held on a PZP and may depend on data fetchedfrom the rest of the personal zone

B Adapting the state of the artPolicies are expressed in a similar way to the format defined

in BONDI [34] However BONDI policies do not support

cross-device interaction The webinos framework thereforemodifies the subject of policies to refer to the device and userPolicies are also able to refer to a dynamically changing setof features as new APIs may be added by new applicationswebinos policies are usually composed in the following waywhere device T is the target device and device R is therequesting device

User U can access Feature F of Device T through applica-tion A on Device R

Figures 3 and 4 show an application requesting access toa remote device feature Every subject (user application anddevice) has an id used to determine if a specific policy shouldbe taken in account when enforcing incoming requests Toperform this selection the Policy Manager tries to match therequestrsquos information against policy targets

ContextPolicies

PolicyEnforcement

TR

U

A 1 Request Position

4 Position

2 Can T return Geolocationrsquos data to

R

3 YES

Fig 3 Example of a request to access a remote devicersquos features ApplicationA launched by user U in set-top box R requires access to geolocation dataprovided by car T

ContextPolicies

PolicyEnforcement

Reply

RequestorDevice

TargetDevice

RequestedAPI

Requestrsquos Info

Request

APP

Fig 4 Every application that requires to access a feature sends a requestwhich is filled with information on the subjects and requested feature

Special URIs are used as ids in policies to match subjectsand services Whenever an entity (user device application orservice) is registered for the first time a record with somebasic identity information is stored These records are used toconvert a generic ID into a convenient URI

There are four basic types of information in the policyrsquossubject The user identified by the URI of their PZH Therequesting device as identified by the TLS certificate issued toeach device when it enrols in a personal zone omitting this in apolicy allows it to apply to applications running on any deviceThe target device similarly identified omitting this allows forpolicies which refer to an API on all devices eg denyingany access to location data Finally the application ID author

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

IV THE webinos POLICY FRAMEWORK

A Basic architectureThe webinos platform provides privacy protection and ac-

cess control features to meet the privacy and security require-ments of web applications and users This means protectingagainst malware and other users who may attempt to accessmore data than they should or simply avoiding the unnecessarydisclosure of personal data To satisfy these requirementswebinos relies on the strong identification of web applicationsusers and devices combined with a least-privilege accesscontrol based on XACML

However while the latest version of XACML introduceda privacy profile specifying two purpose attributes [32] it isstill not well suited for describing data handling policies Forthis reason the XACML architecture has been adapted usingPrimeLife extensions [33] allowing webinos to make accesscontrol decisions based on both the request context and userpreferences

The object model depicted in Figure 2 shows the main com-ponents of the webinos policy framework Both the PZP andPZH enforce policies using standard XACML componentssupplemented by

bull The Decision Wrapper creates the initial policy enforce-ment query based on incoming requests

bull The Access Manager makes the final decision by com-bining XACML access control and DHDF data

bull The Data Handling Decision Function (DHDF) engineprovides privacy and data handling functionalities

bull The Request Context manages all contextual informationit stores all the data and credentials released by a user ina given session

bull The PDP Cache (PDPC) stores PDP decisions that couldbe share among personal devices

PIP

Context Handler

PAP PDPC

PZP

PDP

Data Reader

Request Context

Credential System

Obligations

PEP

DHDF Engine

Access Manager

Decision Wrapper

PZP PZH

Access Requestor

RemoteAccess

Requestor

Overlay Network

PZrsquos copy ofPAP PDPC PIP

Fig 2 Components of the webinos policy framework on a device Requestscome from either local or remote sources and are then managed by theDecision Wrapper Policies are held on a PZP and may depend on data fetchedfrom the rest of the personal zone

B Adapting the state of the artPolicies are expressed in a similar way to the format defined

in BONDI [34] However BONDI policies do not support

cross-device interaction The webinos framework thereforemodifies the subject of policies to refer to the device and userPolicies are also able to refer to a dynamically changing setof features as new APIs may be added by new applicationswebinos policies are usually composed in the following waywhere device T is the target device and device R is therequesting device

User U can access Feature F of Device T through applica-tion A on Device R

Figures 3 and 4 show an application requesting access toa remote device feature Every subject (user application anddevice) has an id used to determine if a specific policy shouldbe taken in account when enforcing incoming requests Toperform this selection the Policy Manager tries to match therequestrsquos information against policy targets

ContextPolicies

PolicyEnforcement

TR

U

A 1 Request Position

4 Position

2 Can T return Geolocationrsquos data to

R

3 YES

Fig 3 Example of a request to access a remote devicersquos features ApplicationA launched by user U in set-top box R requires access to geolocation dataprovided by car T

ContextPolicies

PolicyEnforcement

Reply

RequestorDevice

TargetDevice

RequestedAPI

Requestrsquos Info

Request

APP

Fig 4 Every application that requires to access a feature sends a requestwhich is filled with information on the subjects and requested feature

Special URIs are used as ids in policies to match subjectsand services Whenever an entity (user device application orservice) is registered for the first time a record with somebasic identity information is stored These records are used toconvert a generic ID into a convenient URI

There are four basic types of information in the policyrsquossubject The user identified by the URI of their PZH Therequesting device as identified by the TLS certificate issued toeach device when it enrols in a personal zone omitting this in apolicy allows it to apply to applications running on any deviceThe target device similarly identified omitting this allows forpolicies which refer to an API on all devices eg denyingany access to location data Finally the application ID author

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

ltpolicy-set combine=first-matching-targetgtltpolicy combine=first-applicablegtlttargetgtltsubjectgtltsubject-match attr=user-id

match=Ugtltsubject-match attr=id match=Agtltsubject-match attr=requestor-id

match=Rgtltsubjectgt

lttargetgtltrule effect=permitgtltconditiongtltresource-match attr=api-feature

match=httpwwww3orgnsapi-permsgeolocationgt

ltconditiongtltrulegtltrule effect=denygtltconditiongtltresource-match attr=api-feature

match=gtltconditiongt

ltrulegtltpolicygtltpolicy combine=first-applicablegtltrule effect=denygtltconditiongtltresource-match attr=

api-feature match=gtltconditiongt

ltrulegtltpolicygt

ltpolicy-setgt

Fig 5 Example policy set showing two policies on a device The first policyallows user U (using application A on device R) to access geolocation dataThe second denies access from every other combination of users applicationsand devices

and distributors This is necessary in device domains (such in-car systems) where only applications developed by the devicemanufacturer may access certain resources

Information about the application must be provided by theweb runtime which may be more vulnerable to attack Anadvantage of moving policy enforcement into the PZP is thatthe impact of a malicious web runtime is limited the proxymay be able to assess the state of the runtime and policiesapplying to all applications will still be enforced

Figure 5 gives an example of a policy which would be heldon a local device

C Inter-zone policy enforcement

When web applications are running on different deviceswithin a personal zone access control is managed by thepolicies defined by the user and distributed on each deviceWhen applications in different personal zones are requestingresources (eg Alice accesses Bobrsquos location API) it dependson policies created by both users In this scenario Bob cancreate policies referring to Alice in the subject and thereforecontrol her access to each resource It can be argued that other

attributes in the subject may be omitted as Bob has littleassurance in Alicersquos software and may not trust it to correctlyidentify applications or devices However these fields are stillpresent because Alice and Bob may be able to provide suchassurances eg they may be in the same physical locationand Bob may know exactly which device Alice is using andwhether or not it is trustworthy To save wasted bandwidthfrom denied access requests Alice may chose to implementthe more specific aspects of the policy herself This also makessense when considering trust Bob trusts Alice to only letcertain applications and devices use the resources he has madeavailable to her Alice can do this by creating a policy withinher personal zone where the resource is an API on Bobrsquosdevice but the subjects are her applications and devices Sucha policy would need to be synchronised between all of Alicersquosdevices

V CONCEPTUAL CHALLENGES

A first proof-of-concept of the webinos system has beenspecified and implemented This section will describe threeconceptual challenges that have been experienced when de-signing and developing a cross-domain access control system

A Integration with existing security frameworks

Our experiences with webinos have added weight to theargument that existing browser access control is inadequatefor increasingly sophisticated web applications Browsers tendto either always prevent access to local resources promptthe user for permission or use implicit consent based onuser actions In a multi-device scenario however authorisationprompts cannot always be dictated by just the browser Someapplications require remote access to data and APIs ndash egremote data wiping features for lost or stolen devices andlsquoin case of emergencyrsquo applications 1 These scenarios requiremore than just authorisation prompts and stored decisions

Display capabilities on devices are also different comparea TV to an in-car system which may be displaying route in-formation Browser-style access notifications may be difficultto notice or disrupt the experience of the user The same istrue of how users input their access control decisions Forsome devices such as sensors or embedded systems it mayeven make sense to delegate policy creation to a more capabledevice The webinos security framework was conceived inorder to be flexible enough for all of these settings Adopting acommon policy description language and enforcement frame-work would allow just interfaces to be adapted on individualdevices rather than the whole authorisation system

The integration of webinos with a browser security modelndash a sandbox with time-of-use prompting ndash is in conflict withthe webinos policy-driven approach This means that existingbrowser APIs such as geolocation would need to be changedWe believe this is not necessarily a problem for compatibilityas webinos policies can be configured to behave like browsersFor example access to the geolocation API in the browser

1httpice-appnetwhatishtml

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

results in a user prompt and this decision can be saved perdomain In webinos a policy can be configured to allowor deny access or prompt the user based on applicationcredentials user and device context

B Subject and resource definitions

In a standard access control scenario the resources to beprotected are unequivocally defined as is the access requestorHowever in a multi-device scenario different platforms mayhave different capabilities and implementations and the impor-tance of related assets to be protected will vary For exampleon a smart phone access to telephony capabilities must beprotected whereas on an in-car system the travelling data maybe more important It is therefore difficult to come up witha definition of high medium and low risk permissions in thesame way that the Chrome Web Store does

We assume that each sensitive resource is only exposed by acertain API reducing the problem to the definition of webinosAPIs These had to be specialized in order to cover all thefeatures of each device domain and conversely abstract inorder to describe common features For example many assetsare common to all domains (eg File APIs) some are commonto a subset of sub-domains (eg Telephony for in-car systemsand smartphone) and some are exclusive to a domain (eg TVAPIs) The APIs were designed to support domain-specificapplications but also to facilitate portability of policies (eg auser would like to give an application access to a temporarydirectory for file system access whatever the target device is orgive access to the Telephony API either from his smartphoneor car)

As an added complication the same API can be imple-mented with different technologies on each platform Thegeolocation API can be provided by GPS Cell-ID on smart-phones IP on laptop or fixed ADSL line on a TV set Theimplication in terms of privacy may vary as a result Forexample a user might grant access to the geolocation APIon their PC as this could only reveal their current hometown through IP-based location services If this permissionalso revealed their GPS-derived location while in their car oron their mobile device this could reveal a history of theirmovements and interactions The Telephony API is anotherexample if the end user is roaming on their mobile then thepotential impact of misuse (due to network costs) is greatercompared to a home landline Users might therefore wishto change the authorisation method from lsquoalways allowrsquo tolsquoprompt firstrsquo Policies should be capable of reflecting whichunderlying technology is used and the operating mode of thedevice As a result any default policies will be difficult todefine and may quickly become complicated

C Policy management with varying ecosystems

Actors value chains and liability frameworks are different ineach device domain This means that the policy managementauthority and associated hierarchy can vary from one domainto another as well as the system for provisioning such policiesXACMLrsquos policy combining algorithms make it possible to

write policies for all of these domains The use of XACMLmakes web applications potentially more acceptable in envi-ronments where additional security policies may apply Forinstance when an institutionrsquos employees may be the targetof physical violence (eg animal testing laboratories) policiescould be created limiting access to their location data fromuntrusted web applications

The webinos design decision for the first proof-of-conceptimplementation was to separate policy enforcement from thepolicy storage and deployment system leaving each domain todefine means and rules for policy deployment and compositionof policies from different sources Again this implies that eachdevice will need to be shipped with different access controlpolicies and defaults

D Shared devices

In this paper we have not discussed how to manage deviceswith multiple owners and users There are two distinct sce-narios First devices which have several owners but are onlyused by one person at a time For example a tablet or laptopIn this case multiple personal zone proxies can be installedon each device running under different operating system useraccounts This modifies Figure 1 to add a lsquouser accountrsquo as alevel of indirection between the user and their device

The second case is more complicated some devices are usedby several people at the same time For example a car withseveral passengers or a TV in a shared room At presentwebinos requires that these devices still belong to one userand be part of one personal zone However the user canlimit this device so that it has fewer permissions to accessthe other devices in his or her personal zone This prevents aguest from using it to access resources on the ownerrsquos otherdevices We are also investigating linking the policy systemto authentication such that a policy enforcement point on ashared device can demand additional authentication from theend user This would be OS-specific for example requiringa short PIN entry using a remote control and would thenmake the device capable of accessing other resources andediting local policies This approach is possible (without policyintegration) as part of the defined authentication API [35]However further features are needed to adapt and controlnotifications by applications running on shared devices Forexample a shared device might be prevented from displayingnotifications about private events such as receiving a newemail

VI CONCLUSION AND FUTURE WORK

This paper has argued that existing browser-based au-thorisation methods for JavaScript APIs are insufficient formulti-device context-aware scenarios The policy architecturedeveloped in webinos is proposed as an alternative it makesa number of significant changes from the current state ofthe art showing policies which are both abstract enough tobe transferable to different devices as well as specific toparticular scenarios Our experience in the first implementationof the platform has highlighted several challenges such as

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications

the different implementation of common APIs and how tomanaged shared devices

The main focus of future work will be to continue de-veloping the webinos platform and to further evaluate its ef-fectiveness through several concept applications Other futurework will aim to support the delegation of access controldecisions eg to a tech-savvy friend a user support groupa forum on a social network or a trusted service provider Inaddition we plan to implement tools to support developers inwriting appropriate permissions and designing applications Inparticular allowing developers to trial their applications basedon typical user policies (perhaps gained through user groupsor anonymous feedback) would help identify where too fewor too many permissions were requested as well as whereapplications do not fail gracefully

ACKNOWLEDGEMENTS

The research described in this paper was funded by the EUFP7 webinos project (FP7-ICT-2009-05 Objective 12)

REFERENCES

[1] A Taivalsaari and T Mikkonen ldquoThe web as an application platformThe saga continuesrdquo in Software Engineering and Advanced Applica-tions (SEAA) 2011 37th EUROMICRO Conference on September 2011pp 170 ndash174

[2] ldquoGeolocation API Specification W3C Editorrsquos Draftrdquo httpdevw3orggeoapispec-sourcehtml February 2010

[3] ldquoDevice APIs Working Group Websiterdquo httpwwww3org2009dapDecember 2011

[4] ldquoBmw connecteddriverdquo April 2012 [Online] Avail-able httpwwwbmwcomcomeninsightstechnologyconnecteddrive2010infotainmentinformationinternet informationhtml

[5] L Jedrzejczyk B A Price A K Bandara and B Nuseibeh ldquoOnthe impact of real-time feedback on usersrsquo behaviour in mobilelocation-sharing applicationsrdquo in Proceedings of SOUPS rsquo10 ACM2010 pp 141ndash1412 [Online] Available httpdoiacmorg10114518371101837129

[6] The W3C ldquoMobile Web Application Best Practicesrdquo De-cember 2010 [Online] Available httpwwww3orgTR2010REC-mwabp-20101214

[7] The Wholesale Application Community ldquoGlossary of termsrdquo August2011 [Online] Available httpwwwwacappsnetglossary

[8] M Zalewski The Tangled Web A Guide to Securing Model WebApplications No Starch Press 2011

[9] ldquoWidget Access Request Policy W3C Recommendationrdquo February2012 [Online] Available httpwwww3orgTRwidgets-access

[10] W Enck M Ongtang P McDaniel W Enck M Ongtang andP McDaniel ldquoUnderstanding Android Securityrdquo Security Privacy IEEEvol 7 no 1 pp 50 ndash57 Jan - Feb 2009

[11] A P Felt K Greenwood and D Wagner ldquoThe effectiveness ofapplication permissionsrdquo in Proceedings of the 2nd USENIX conferenceon Web application development ser WebAppsrsquo11 Berkeley CAUSA USENIX Association 2011 pp 7ndash7 [Online] Availablehttpdlacmorgcitationcfmid=20021682002175

[12] A Beresford A Rice N Skehin and R Sohan ldquoMock-droidtrading privacy for application functionality on smartphonesrdquo inProceedings of HotMobile 2011 2011 [Online] Available httpwwwclcamacukresearchdtgandroidmock

[13] M Nauman S Khan and X Zhang ldquoApex extending androidpermission model and enforcement with user-defined runtimeconstraintsrdquo in Proceedings of the 5th ACM Symposium on InformationComputer and Communications Security 2010 pp 328ndash332 [Online]Available httpdoiacmorg10114517556881755732

[14] M Conti V Nguyen and B Crispo ldquoCrepe Context-related policyenforcement for androidrdquo in Information Security ser Lecture Notes inComputer Science M Burmester G Tsudik S Magliveras and I IlicEds Springer Berlin Heidelberg 2011 vol 6531 pp 331ndash345[Online] Available httpdxdoiorg101007978-3-642-18178-8 29

[15] N Reddy J Jeon J A Vaughan T Millstein and J S FosterldquoApplication-centric security policies on unmodified androidrdquo UCLAComputer Science Department Tech Rep 110017 2011 [Online]Available httpfmdbcsuclaeduTreportsacp-trpdf

[16] ldquoSEAndroid Websiterdquo httpselinuxprojectorgpageSEAndroid March2012

[17] ldquoWAC Specifications 21rdquo httpspecswacappsnet January 2012[18] S Godik and T Moses ldquoEXtensible Access Control Markup Language

(XACML) version 11rdquo httpwwwoasis-openorg May 2005[19] ldquoPrimelife policy languagerdquo httpwwwprimelifeeuresultsdocuments

153-534d August 2010[20] Claudio A Ardagna et al ldquoAdvances in access control policiesrdquo in

Privacy and identity management for life Springer 2011 pp 327ndash341

[21] D Lin and A Squicciarini ldquoData protection models for serviceprovisioning in the cloudrdquo in Proceedings of SACMAT ACM 2010pp 183ndash192 [Online] Available httpdoiacmorg10114518098421809872

[22] Y-G Kim C-J Mon D Jeong J-O Lee C-Y Song and D-K BaikldquoContext-aware access control mechanism for ubiquitous applicationsrdquoin Advances in Web Intelligence ser Lecture Notes in ComputerScience Springer Berlin Heidelberg 2005 vol 3528 pp 932ndash935[Online] Available httpdxdoiorg10100711495772 37

[23] A Corradi R Montanari and D Tibaldi ldquoContext-based access controlmanagement in ubiquitous environmentsrdquo in Network Computing andApplications 2004 (NCA 2004) Proceedings Third IEEE InternationalSymposium on aug-1 sept 2004 pp 253 ndash 260

[24] Mazurek et al ldquoAccess control for home data sharing Attitudes needsand practicesrdquo in Proceedings of the 28th international conferenceon Human factors in computing systems ser CHI rsquo10 NewYork NY USA ACM 2010 pp 645ndash654 [Online] Availablehttpdoiacmorg10114517533261753421

[25] M Baldauf S Dustdar and F Rosenberg ldquoA survey on context-awaresystemsrdquo International Journal of Ad Hoc and Ubiquitous Computingvol 2 no 4 pp 263ndash277 June 2007

[26] H J Wang C Grier A Moshchuk S T King P Choudhury andH Venter ldquoThe multi-principal os construction of the gazelle webbrowserrdquo in Proceedings of the 18th conference on USENIX securitysymposium ser SSYMrsquo09 Berkeley CA USA USENIX Association2009 pp 417ndash432 [Online] Available httpdlacmorgcitationcfmid=18557681855794

[27] R S Cox S D Gribble H M Levy and J G Hansen ldquoAsafety-oriented platform for web applicationsrdquo in Proceedings ofthe 2006 IEEE Symposium on Security and Privacy ser SP rsquo06Washington DC USA IEEE Computer Society 2006 pp 350ndash364[Online] Available httpdxdoiorg101109SP20064

[28] K Singh A Moshchuk H J Wang and W Lee ldquoOn the incoherenciesin web browser access control policiesrdquo in Security and Privacy (SP)2010 IEEE Symposium on may 2010 pp 463 ndash478

[29] C Ai J Liu C Fan X Zhang and J Zou ldquoEnhancing personal infor-mation security on android with a new synchronization schemerdquo in Wire-less Communications Networking and Mobile Computing (WiCOM)2011 7th International Conference on sept 2011 pp 1 ndash4

[30] The webinos consortium ldquoUser expectations of privacy and securityrdquoMarch 2011 [Online] Available httpwebinosorgblog20110316d2-3-industry-landscape-ipr-licensing-governance

[31] mdashmdash ldquoUse cases and scenariosrdquo March 2011 [Online] Available httpwebinosorgblog20110322webinos-report-use-cases-and-scenarios

[32] E R B Parducci H Lockhart ldquoXACML v30 Privacy Pol-icy Profile Version 10rdquo httpdocsoasis-openorgxacml30xacml-30-privacy-v1-spec-cd-03-enpdf March 2010

[33] C A Ardagna S De Capitani di Vimercati S Paraboschi E Pedriniand P Samarati ldquoAn xacml-based privacy-centered access control sys-temrdquo in Proceedings of the first ACM workshop on Information securitygovernance ser WISG rsquo09 ACM 2009 pp 49ndash58

[34] ldquoBondi architecture and security requirements appendicesrdquohttpbondiomtporg101securityBONDI Architecture andSecurity Appendices v1 01pdf July 2009

[35] The webinos consortium ldquoPhase 1 device networkand server-side api specificationsrdquo November 2011[Online] Available httpwebinosorgblog20111101webinos-report-phase-i-device-network-and-server-side-api-specifications