Privacy Preservation in Context-Aware Systems By: Pramod Jagtap Master’s Thesis Defense Advisor: Dr. Anupam Joshi Let’s start this presentation with some facts! 91% of Americans are mobile phone subscribers.  Among that around 50% are smartphone users. It turns out to be 140 million americans have smartphones. Which includes Blackberry, Iphone, Android-based phones. 155 million americans are on facebook. More specifically around 30 millions are using location-based services like fourquare, facebook check-in, loopt. Pretty impressive numbers ! What’s the relation of these numbers and my thesis ? I believe it will help us to understand the magnitude of the problem statement.

9/20/2018 The Wall Street Journal Today's smartphones are programmable devices. It comes up with large set of cheap powerful embedded sensors. Thousands of smartphone applications, or "apps," already take advantage of a user's location data to forecast traffic congestion, rate restaurants, share experiences and pictures, or localize radio channels. Applications can access the handset logs such as calling data, messaging activity, search requests and online activities. The researchers are using this information to gauge behavior, to capture the swings in national mood that presaged the changes in stock market. The problem here is that the sensor information is personal to the users. Users are sensitive about how the sensor information is captured and used. If this information is not handled properly then it will create new controversies. In the last week itself it was reveled that the iPhone devices contains a detailed unencrypted log of device’s location. The log file contains users location history of several months. Two data scientists wrote a simple program to visualize this information which is shown here. Who cares ? I have nothing to hide ! What if your phone is stolen or hacked ? You can imagine the consequences! Location is captured by the one of the many sensors available. One can use all of these sensors to collect information about the user. Then we have social networks and location based services where users share their profile information, photos, videos, what they are thinking or doing …It is shared with friend, friends or friends or everyone ! There is ongoing work to fuse the information from users smartphones and other online sources to easily infer user’s context. This context includes current location, activity, surroundings, movements, relationships, moods, health, calling habits and spending. Researchers at MIT carried out a similar experiment. They gave volunteers free Android smartphones equipped with software that automatically logged their activities and their proximity to other people. After some time they were able to deduce users political opinions and how it is changed by different factors. The context information and sensor information is critically sensitive to the users and hence should be protected. The privacy-related debate is occurring over the type of information that context-aware systems should be able to access. We don’t have full-fledge laws in place to ensure that user’s information is protected. In this scenario, the onus of protecting information is on user. The Wall Street Journal 9/20/2018

Currently the privacy controls in context aware systems are based on static information and predetermined. User can decide information sharing based on static information such as group of friends, profile information attributes. This controls are not adequate for context-aware systems. The context-aware systems has heterogeneous and dynamic sensors which causes continuous changes in user’s context. This environment calls for better access controls with finer control over context data. We need privacy mechanisms that consider the dynamic changes in user context relative to location and time. The user needs to be in control of the release of her personal information at different levels of granularity, from raw sensed data to high level inferred context information. The users should be able to define their privacy policies and the context-aware system should be able to protect their information regardless of application. The context-aware system can have complex privacy policies. Consider healthcare context-aware system where sensor-enabled mobile phones can be used to collect in situ sensor data and context data about patient and caretakers. The user of such system can have privacy policy like “In case of minor medical problems, share my recent medical records and caretaker’s city-wide location with doctor but in case of emergency, share my detailed medical data, location history and current location of caretaker” In another case, the user can have a policy like “Do not share my GPS information with anyone if I am speeding on some highway”. None of the existing context-aware systems allow users to specify such privacy preferences. 9/20/2018

What We Need ! Static Information Aspects of Context Generalization of Context Temporal Restrictions The current state of context-aware system prompts the need of privacy control model to control the information flow in the system based on ever-changing context of the users. None of the existing models allows users to specify such policies based on this information. It motivated us to build a privacy framework to protect the user’s privacy based on dynamic aspects of context-aware system along with user’s profile and group information. The framework should consider user’s context, requester’s context, temporal restrictions, context restriction before making access control decisions. It should allow users to share context information on different levels of accuracy. Requester’s Context Context Restrictions 9/20/2018

This Thesis is About ! Presenting a policy-based framework to protect user privacy in context-aware system based on context of both owner and requester Validation of the framework in a prototype system Evaluation of the framework on mobile devices In this thesis I present you a policy-based framework which ensures that user’s context information and sensor information is shared on the basic of user-defined privacy policies. We have validated our framework in a campus-based prototype system with sample policies. We have evaluated this framework on mobile devices by successfully performing reasoning on these devices. 9/20/2018

Agenda Introduction Related Work and Motivation System Architecture Prototype Implementation Results Conclusion and Future Work 9/20/2018

What is Context? “Set of environmental states and settings in which an  application event occurs and is interesting to the user” (Chen and Kotz - 2000) Defined by a combination of relevant environmental properties, participants, and participant's activities User context : user's role, location, activity, people nearby Time context Physical context Computing context The important aspects of context are: (1) where you are; (2) who you are with; and (3) what resources are nearby. Computing context (network connectivity, communication costs, and communication bandwidth, nearby resources) User context (user's role, location, people nearby) Physical context (lighting, traffic conditions) Time context (time of a day, month, and season of the year) Mostly classified as location, identity, activity and time 9/20/2018

Related Work and Background The context-aware electronic tourist guide (Cheverst et al. 2000) AnonySense (Shin et al. 2010), a privacy-aware architecture for collaborative pervasive applications that use mobile sensing Project Aware Home (Kidd et al. 1999) uses RBAC based access control model Context Privacy Service (CoPS) (Sacramento, Endler, & Nascimento 2005) describes the design and implementation of a privacy service Context-aware systems have been studied from long time. The context-aware electronic tourist guide contributed by developing location-aware tour guides which provided tourists with information depending on their location. AnonySense is a privacy-aware architecture for collaborative pervasive applications that use mobile sensing. Mobile sensor data is anonymized before its use by any of the applications. Project Aware Home captures, processes and stores the data about home residents and their activities. It uses access control mechanisms based on RBAC by defining environment roles similar to subject roles of RBAC. Context privacy service describes a privacy service which control how, when and to whom you could disclose a user’s context information. 9/20/2018

Related Work Rei is a policy language based in OWL-Lite (Kagal et al.) Rein (Rei and N3) (Kagal & Berners-lee 2005) : Distributed framework for describing and reasoning over policies in the Semantic Web AIR (Kagal, Hanson, & Weitzner 2008) : Policy language that provides automated justification support by tracking dependencies during the reasoning process. Uses Truth Maintenance System (Doyle 1978) to track dependencies. 9/20/2018

System Architecture Server side Client devices Social Media Calendar Data Content Aggregator DB Server side Learn and share Privacy control module Privacy enforcement at server side Network Privacy enforcement over Sensed data We are using a university-campus based prototype system. The major components of this system are client devices, server side modules and the Internet services that provide social media. The client devices are location aware smartphones which comes up with large set of sensors. These client devices as well as the server side modules contain a user profiles information, a privacy control module and privacy preferences. The server side also contains a content aggregator, a learn and share module and a privacy control module. The content aggregator combines social media like event updates, photos, and videos from Internet services like YouTube, Flickr, Facebook or university information portals. The learn and share module infers the user’s dynamic context using sensor data collected by a variety of sensors on the phone, the information from the content aggregator and online sources such as user’s calendar. This contextual information is shared with client devices. Privacy control module Privacy control module Privacy control module Client devices Sensor Data Sensor Data Sensor Data Privacy enforcement between Peer devices 9/20/2018

Content Aggregation 9/20/2018

System Architecture Social Media Calendar Data Content Aggregator DB Learn and share Privacy control module Privacy enforcement at server side Network Privacy enforcement over Sensed data The learn and share module has user’s sensor data, profile and group information collected by content aggregator. It infers the user’s dynamic context by using this information. This contextual information is shared with client devices. In our Ebiquity lab, we have done some work of part of content aggregator, learn and share module. In this system, the context information and sensed information is shared between two client devices and between a client device and server. To ensure that user’s information is protected we need privacy enforcement to be done at different ways of information sharing. Sharing the sensor information to the server: Here the sensor information Sharing information between a server and client : Information sharing between two clients : A client device can send context access query to another client device. The other client will decide what information can be shared with requester based on it’s owner’s privacy policies. In this case, the reasoning is done over the mobile devices in reasonable time. This is one of the achievements of this thesis. Privacy control module Privacy control module Privacy control module Sensor Data Sensor Data Sensor Data Privacy enforcement between Peer devices 9/20/2018

Privacy Control Module It deals with the resource to be protected, the owner of a resource and the requester who wants to access it Aims to protect user privacy in a context-aware system by enforcing user privacy policies The privacy control module is responsible for protecting the context information and sensed data. It deals with the resource to be protected, the owner of a resource and the requester who wants to access it. It aims to protect user privacy in a context-aware system by enforcing user privacy policies. 9/20/2018

Privacy Control Module - Context Ontology 9/20/2018

Privacy Control Module - Context Ontology It captures the user location and surroundings, the presence of other people and devices, and the inferred activities in which they are engaged The context-aware systems raise the need of models for representing and reasoning about a more inclusive and higher-level notion of the context. It defines the key context concepts used for making access control decisions. We have used OWL (Web Ontology Language), and associated inferring mechanisms to develop a model of context and policies. As shown in the fig. the principal which can be a user has a role in activity. Using the ontology, each device contains a declarative knowledge base with semantically rich information about user, her context and inferences. 9/20/2018

Privacy Control Module - Context Ontology Supports the generalization of contextual information Location Generalization Activity Generalization Generalization involves replacing (or recoding) a value with a less specific but semantically consistent value. A user can opt to share less accurate information with requester to protect her privacy. One of the biggest challenge that the researchers are facing now is “how to use generalization effectively to protect user privacy” It helps the user to have finer control over her contextual information and hence to share information on different levels of granularity. E.g. User can have a policy like “Share my less accurate activity with friends if I am on date with someone known to them and city-level location to my family” 9/20/2018

Privacy Control Module - Context Ontology Location Generalization: Share my location with teachers on weekdays from 9am-5pm User’s exact location in terms of GPS co-ordinates is shared The user may not be interested to share GPS co-ordinates but fine with sharing city-level location Share my building-wide location with teachers on weekdays from 9am-5pm This approach has its own limitations as it doesn’t allow sharing on different granularity levels of the location. In many cases the user might be interested to share the location but not in terms of GPS coordinates. 9/20/2018

Privacy Control Module - Context Ontology Location Generalization: Our ontology uses hierarchical model of location to support location generalization The transitive “Part Of” property creates the location hierarchy 9/20/2018

Privacy Control Module - Context Ontology Activity Generalization Share my activity with friends on weekends User’s current activity is shared with friends on weekends share more generalized activity rather that precise confidential project meeting => Working, Date => Meeting User clearly needs to obfuscate certain pieces of activity information to protect her context information Share my public activity with friends on weekends Public is a visibility option It will enable users to have default privacy policies based on different accuracy levels. 9/20/2018

Activity Generalization 9/20/2018

Privacy Control Module – Knowledge About User 9/20/2018

Privacy Control Module – Knowledge About User Profile and context information - represented using N3 platys:Professor_Meeting a platys:Activity ; platys:is_performed by ex:Alice ; platys:has_participant ex:Alice, ex:John ; platys:occurs_at platys:Class LH1 ; platys:occurs_when “2010-11-19T14:12:42”. platys:Class LH1 a platys:Place ; platys:has_location “39.253525, -76.710706”. platys:GPS a platys:Point ; platys:part_of platys:ITE_325 . platys:ITE_325 a platys:Room ; platys:part_of platys:ITE . platys:ITE a platys:Building ; platys:part_of platys:Baltimore . platys:Baltimore a platys:City ; platys:part_of platys:Maryland . platys:Maryland a platys:State . ex:Alice a foaf:Person ; foaf:name “Alice” ; ex:systemUser “true” ; platys:has role platys:Student . The system has user’s profile information, group information and contextual information. It is represented in N3 and shown here. User’s profile information can contain name, email address, hobbies, interests. 9/20/2018

Privacy Control Module – Knowledge About User Group Information ex:Harry a foaf:Person ; foaf:name “Harry” ; ex:memberOf ex:GroupFamily . ex:Ron a foaf:Person ; foaf:name “Ron” ; ex:memberOf ex:GroupFriends . ex:GroupFamily a foaf:Group ; foaf:name “Family” . ex:GroupFriends a foaf:Group ; foaf:name “Friends” . 9/20/2018

Privacy Control Module – Privacy Preferences 9/20/2018

Privacy Control Module - Privacy Preferences Access control rules that describes how the user wants to share her information, with whom, and under what conditions Information can be profile information, context Different groups of requesters Condition can be user’s or requester’s context Represented in N3 User-defined and System-defined privacy policies 9/20/2018

Privacy Control Module - Privacy Preferences User-defined policies : specified by the user to protect her information Share my context with family members all the time System-defined policies Can be needed for military domains or organizations Multi-level secure systems where the system-level policies must override the user-level policies Do not share the user’s context if she is inside a military building BuildingXYZ 9/20/2018

Policy Editor To specify and edit privacy policies. The policies are created and stored in N3 format on both server and client sides in persistent memory 9/20/2018

Privacy Control Module – Reasoning Engine 9/20/2018

Privacy Control Module – Reasoning Engine Handles the requester queries and performs reasoning for access control decisions Jena Semantic Web framework Implement both the RDFS and OWL reasoner These reasoners are used to infer additional facts from the existing knowledge base coupled with ontology and rules 9/20/2018

Reasoning Architecture Platys ontology (.owl) Static user facts (.N3) OWLReasoner Inference Model Save model to file system Saved Model (RDF/XML) Load Model Requester’s context information (.N3) Dynamic knowledge about user (.N3) Inference Model System rule- set (.N3) Generic Rule Reasoner Inference Model User-defined rule-set (.N3) Generic Rule Reasoner Inference Model It contains user’s access levels and corresponding triples 9/20/2018

Privacy Preservation The user’s personal information can be shared between a client device and the server or between two client devices Privacy enforcement needs to be done on Client devices over sensed data Peer client devices Server side for contextual information Let’s go over few sample policies to protect user’s information in a university-campus based system. 9/20/2018

Privacy Enforcement between Client Devices Requester : another client device Can send requester’s context along with request Resource : owner’s contextual information or sensor information. Privacy Policies : defined by owner of client device 9/20/2018

Sample Privacy Policies Policy to share context information based on user’s profile and group information: Share detailed contextual information with family members all the time [AllowFamilyRule: (?requester a ex:requester) (?requester ex:memberOf ?groupFamily) (?groupFamily foaf:name “Family”) -> (?requester ex:contextAccess ex:userPermitted) ] User can opt to have policy to share information based on profile and group information. 9/20/2018

Sample Privacy Policies Policy to share context information based on the user’s context : Share my activity with friends all the time except when I am attending a lecture [ShareActivityWithFriendsRule: (?requester a ex:requester) (?requester ex:memberOf ?groupFriends) (?groupFriends foaf:name “Friends”) (?someActivity platys:is performed_by ex:Alice) notEqual(?someActivity, platys:Listening_To_Lecture) -> (?requester ex:activityAccessRule :policy5) ( :policy5 ex:activityAccess ex:userPermitted) ] 9/20/2018

Sample Privacy Policies Policy for sharing information based on temporal restriction Do not share my sleeping activity with teachers on weekdays from 9am-9pm Policy for information sharing based on requester’s context Share my context with anyone attending same class as me 9/20/2018

Sample Privacy Policies Policies using generalization for sharing Share my activity with friends if it’s public Share my public activity with friends Share my city-wide location with everyone System-level policies Do not share user’s context if she is inside BuildingXYZ 9/20/2018

Privacy Enforcement over the Sensed Data Let users decide how their sensor information is released Sample Privacy policy : share GPS co-ordinates on weekdays from 9am-5pm only if he is in office [ShareGPSRule: (?requester ex:requestTime ?localTime) (?user ex:systemUser ?true) (?localTime time:dayOfWeek ?day) ge(?day, 1) le(?day, 6) (?localTime time:hour ?hour) ge(?hour, 9) le(?hour, 17) (?user ex:Latitude ?latitude) (?user ex:longitude ?longitude) Equal(?latitude, ?officeLat) Equal(?longitude, ?officeLong) -> (?requester ex:canAccessGPSCoordinates “True”) ] 9/20/2018

Privacy Enforcement over the Sensed Data Sample privacy policy : Do not allow access to recorded audio but allow access to accelerometer and WiFi AP ids on weekdays [ShareAccelerometerRule: (?requester ex:requestTime ?localTime) (?localTime time:dayOfWeek ?day) ge(?day, 1) le(?day,6) -> (?requester ex:canAccessAccelerometerReadings “True”) (?requester ex:canAccessWiFiIds “True”) (?requester ex:canAccessAudioData “False”) ] 9/20/2018

Privacy Enforcement at Server side The server has information about all the system users whereas a client device has information about it’s owner only Request to server should contain the specific userId 9/20/2018

Privacy Enforcement at Serverside Allow location access to teachers on weekdays only between 9am – 6pm [ShareActivityWithTeachersRule: (?requester ex:memberOf ?groupTeachers) (?groupTeachers foaf:name “Teachers”) (?requester ex:requestTime ?localTime) (?localTime time:dayOfWeek ?day) ge(?day, 1) le(?day, 6) (?localTime time:hour ?hour) ge(?hour, 9) le(?hour, 18) (?user ex:systemUser ?true) Equal(?user, ?userId) -> (?requester ex:activityAccessRule :policy6) ( :policy6 ex:activityAccess ex:userProhibited) ] 9/20/2018

Prototype Implementation Google Android phone as client devices It uses sockets to establish two-way communication link between a server and clients Defined a generic request and response formats We have built one prototype to share information between devices and server. 9/20/2018

System Implementation Android client and server applications user interface Context Request Send Response 9/20/2018 Bob’s Phone Alice’s Phone

System Evaluation The goals of evaluation were to Verify whether the system satisfies a basic criteria by allowing access from privileged users and restricting illegal users Test whether the actual computing time of reasoning over mobile devices is acceptable Perform scalability tests : determine how it scales with different size of user information like number of users in group list The privileged user is a requester who is allowed to access user’s context as per user-specified privacy rules whereas other’s are modeled as illegal users. 9/20/2018

System Validation Designed use cases with sample user information, group information and privacy policies. Changed the requester or requester context in each of these use cases and verified system response in terms of access levels for requester System-level policies and user-specified policies 9/20/2018

System Validation System-level policies : User-specified policies : Share detailed context information with family members Share user’s building-wide location with teachers on weekdays only between 9 am and 6 pm Share user’s citywide location with everyone Do not share user’s super-private activities with anyone User-specified policies : Do not share my context if I am in a meeting with Professor Share my Semipublic activity with friends Do not share my sleeping activity with teachers on weekdays between 9am-9pm Do not share my context when I am partying Share my working activity with my family Share my room-wide location with everyone in the same building as me Share my context with anyone attending same class as me 9/20/2018

System Validation Use case : Context access request from requester Ron (a family member) Expected Response : Grant context access by system-level policy “Share detailed context information with family members” 9/20/2018

System Validation Use case : request from requester Bob (a friend) Expected Response : Not allowed to access user’s detailed context. Only SemiPublic activity and citywide location can be shared. Share user’s citywide location with everyone - System level policy Share my Semipublic activity with friends – User-specified policy Response to a context access query. Response to a activity access query. Response to a Location access query. 9/20/2018

System Validation Use case : Request from “unknown” requester Expected Response: Share my context with anyone attending same class as me Response to “unknown” requester with different context than attending same class as user. Response to “unknown” requester attending same class as user. 9/20/2018

System Performance Measured reasoning time taken for the request on both server machine and Android device Numbers of users On server machine On Android device Reasoning time(ms) Standard deviation 10 1177 142 1128 13 50 1246 74 1446 46 100 1993 26 1903 118 250 2448 184 2682 165 500 3042 108 4233 245 1000 3715 456 10896 393 Reasoning on mobile devices can be done without any scalability issues and it can be efficiently used to enforce privacy over sensed and contextual data 9/20/2018

System Performance Reasoning time (in milliseconds) for different number of users in owners group list 9/20/2018

Future Work Extend the prototype implementation to address the engineering challenge of scalability Carry out user studies to evaluate the utility of the proposed privacy control mechanisms Address the issues of incorporating incentives to allow for even more flexibility in the definition of policies for context-dependent release of information 9/20/2018

Conclusion Described a policy based framework to control information flow in collaborative context aware geo-social networking application Showed example policies that state of the art systems do not support Our privacy mechanisms constitute a baseline that can be extended and incorporated by any of the existing social networks including location based mobile social networks It allows users to specify a rich suite of privacy preferences that consider the static and dynamic knowledge about user, along with generalization rules to regulate the accuracy of results. 9/20/2018

Dr. Anupam Joshi Dr. Tim Finin Dr. Yelena Yesha Dr. Laura Zavala Friends Roommates 9/20/2018

? 9/20/2018

Motivation Need of privacy control models to control the information flow in collaborative context-aware geo-social networking applications based on the context of both owner and requester None of the existing models allow users to specify the privacy preferences based on this information 9/20/2018