privacy policies change management for smartphones
DESCRIPTION
The ever increasing popularity of apps stems from their ability to provide highly customized services for the user. The flip side is that to provide such customized services, apps need access to very sensitive personal user information. This has led to a lot of rogue apps that e.g. pass personal information to 3rd party Ad servers in the background. Studies have shown that current app vetting processes which are mainly restricted to install time verification mechanisms are incapable of detecting and preventing such attacks. We argue that the missing fundamental aspect here is the inability to capture and control runtime characteristics of apps, e.g. we need to know not only the list of sensors that need to be accessed by an app but also their frequency of access. This leads to the need for an expressive policy language that in addition to the list of sensors, also allows specifying when, where and how frequently can they be accessed. An expressive policy language has the disadvantage of making the task of an average user more difficult in setting and analyzing the consequences of his privacy settings. Further, privacy polices evolve over time. Over time, users are likely to change their privacy settings, as a response to a recently discovered vulnerability, or to be able to install that “much desired” app, etc. Such a policy change affects both already installed (may no longer be compliant) and previously rejected apps (may be compliant now). In this paper, we propose an integrated privacy add-on that (i) compares the apps profiles vs. user’s privacy settings, outlining the points of conflict as well as the different ways in which they can be resolved. And (ii) provides efficient change management with respect to any changes in user privacy settings.TRANSCRIPT
Nokia Research Center
Privacy Policies Change
Management for
Smartphones
Debmalya Biswas
Nokia Research Center, Switzerland
MUCS 20121
Nokia Research Center
Smart phones
Sensors
The average smartphone nowadays consists of many sensors:
• GPS
• Accelerometer
• Bluetooth, Wifi
• Proximity
• Rotation
• Magnetometer
• Ambient Light
MUCS 20122
Nokia Research Center
Smart phones
Intelligent and Contextual Apps
• GPS – Real-time precise location
• Accelerometer - Activity, e.g. the speed at which the user is moving his
hand
• Compass – the direction
• Bluetooth – Nearby people
Traditional input devices, e.g. Camera, Microphone
and
sources of information, e.g Messeges, Address book, Pics, Vids (file
system in general)
MUCS 20123
Nokia Research Center
State of the Art
Install-time verification
• Certification: Centrazilized certification by the App Store
• Capabilities based access control model:
• Capabilites here refers to group of phone resources
• Apps have to declare the phone capabilities/resources they need to access
• If allowed by user, the app is installed with tokens to access the requested resources.
• Certification + Capabilities
Many real-life cases of malicious apps bypassing the above safeguards.
MUCS 20124
Nokia Research Center
Missing Aspects
Run-time parameters
• Frequency: An app A is allowed to access a sensor S only with a certain
frequency.
• A weather app does not need to access your location every 5 seconds.
Contextual parameters
• Time, Location:
• An app A is NOT allowed to access the phone’s camera/microphone when the user is in
(location) Offce.
MUCS 20125
Nokia Research Center
Real-time and Contextual Policies
• Sequence of invocation:
• Implicitly includes the list of allowed sensors
• Frequency: of access f.
• Time range: (sT, eT) and r.
• r refers to the recurrence patterns e.g. daily, weekly, yearly
• Location: Set of allowed locations L.
• Can refer to both geogrpahic (e.g. city, country) and semantic locations (e.g. home, office)
MUCS 20126
Nokia Research Center
Policy Language
Metric Temporal Logic
• Only sensors s1, s2 and s3 can be invoked; s2 within 30 mins of s1’s
invocation, folllowed by s3 within the next 40 minutes.
• Logical operators: AND ˄, OR ˅, NOT¬
• Temporal operators: Past ♦, Furture ◊
• Metric: Quantification [sT, eT]
Formalism can be used to express both App profiles AP and User
privacy policies uP.
MUCS 20127
Nokia Research Center
Conflict Detection
App profile aP:
sens(s1,fa, …, {l1,la}) ˄ ◊[5,15] sens(s2,f2, …)
User privacy profile uP:
sens(s1,fu, …, {l1,lu})
• List of sensors:
• Conflict: s2 is not allowed by user
• Frequency:
• Conflict: fa > fu
• Location:
• Conflict: la is not allowed by user
MUCS 20128
Nokia Research Center
Conflict Resolution
App profile aP:
sens(s1,fa, …, {l1,la}) ˄ ◊[5,15] sens(s2,f2, …)
User privacy profile uP:
sens(s1,fu, …, {l1,lu})
• Reject the app.
• Relax user privacy profile:
• uP: sens(s1,fa, …, {l1,lu,la}) ˄ ◊[5,15]
sens(s2,f2, …)
MUCS 20129
Nokia Research Center
Policy Evolution
App profile aP:
sens(s1,fa, …, {l1,la}) ˄ ◊[5,15] sens(s2,f2, …)
User privacy profile uP:
sens(s1,fu, …, {l1,lu})
• Relax:
• uP: sens(s1,fa, …, {l1,lu,la}) ˄ ◊[5,15]
sens(s2,f2, …)
• Restrict:
• uP: sens(s1,fa, …, {l1,la}) ˄ ◊[5,15]
sens(s2,f2, …)
MUCS 201210
Nokia Research Center
Policy Evolution
• Policies evolve over time
• Security advisories
• Change in physical characteristics, e.g. location, occupation
• Restrict:
• Re-evaluate already installed apps to see if they are still compliant
• Relax:
• Re-evaluate previously rejected apps to see if they are now compliant
• Maintain log of rejected apps categorized by their conflict types
• Relax + Restrict:
• Policy change can be both relaxing and restricting at the same time
MUCS 201211
Nokia Research Center
Conclusion
• Problem: Regulating access by 3rd party apps to sensors on the phones.
• Expressive install-time privacy policy language
• Run-time and contextual parameters
• Temporal Logics based conflict detect and resolution.
• Policy evolution categorization
• Can lead to installation of previously rejected apps
• Automated validation of installed apps in the event of any policy changes
MUCS 201212
Nokia Research Center
Thank You
&
Questions
MUCS 201213