Embed Size (px)
Citation preview
PrivacyInformer: Automatic Privacy Description Generator for MIT App Inventor
Daniela Miao Aug 7th, 2014 1
At a glance • Motivation • Overview of the System
– User Interface – Project Source Analysis – Mobile Integration
• Exploratory User Study • Policy Discussion • Future Work & Summary
2
Motivation
3
• Many privacy concerns in the mobile apps market
• Privacy policies provide one method to inform end users, but they are usually long and difJicult to understand – Would take one month to read all privacy policies of websites an average user visits in a year
• Mobile apps developers don’t like to write privacy policies
Motivation
4
• App Inventor developers use visual components, so we can automatically generate privacy documents by analyzing the “source code”
• Pre-‐generated templates can be associated with privacy-‐sensitive components – One for location sensor, one for accelerometer sensor etc.
• Final privacy description is generated at compile time
Privacy Policy vs. Privacy Description • Online privacy policy generators help developers with legal preparation – ensures regulations are followed
• PrivacyInformer generates a short, usable privacy document, contents are not vetted by legal experts
• Privacy description focuses on describing just the privacy-‐sensitive behaviors of the application
5
Permissions vs. Privacy Description • Permissions cover broad classes of functionalities, offering little meaningful information to users
• PrivacyInformer analyzes blocks code in an attempt to convey behaviors, and how data is collected and disseminated 6
7
System Overview
1. User Interface – Adding the new view for PrivacyInformer – Integration with current App Inventor UI
2. “Source code” Analysis – Find Jiles that store component and blocks info – Parse, analyze and extract information to construct
intermediate data structure – Linked Data – Produce human-‐readable privacy description
3. Packaging the generated privacy description into the compiled apk at build time
– Make it viewable via Android menu options 8
System Overview
9
User Interface
• Real-‐time access of project “source” needed • Find source Jiles: JSON and XML
“Source code” Analysis
JSON XML
• Intermediate data structure needed to represent the privacy description of each application
• Linked Data (LD) is Jlexible – just needed to create relevant ontological terms to deJine App Inventor and Android concepts – Hosted at http://dig.csail.mit.edu/2014/PrivacyInformer
• Privacy description generated in Linked Data format by combining pre-‐generated LD templates for privacy-‐sensitive components, as well as analyzing relationships between blocks
11
“Source code” Analysis
• Privacy templates are created for a pre-‐deJined set of “privacy-‐sensitive” components – For testing purposes: AccelerometerSensor, LocationSensor, Web
• Templates contain information that is unlikely to change: function of the component, what permissions it has etc.
12
“Source code” Analysis
• Source Jile provides a list of privacy-‐sensitive components used
• Appropriate templates are included in the privacy description of the application
13
“Source code” Analysis Privacy Templates
Generated Description
• Details for LocationSensor
• Details for Web JSON
• Blocks source code analyzed to capture pair-‐wise interactions between privacy-‐sensitive components
• Certain methods are pre-‐deJined as “potentially privacy leaking” 14
“Source code” Analysis
Accelerometer:Shaking ai:connectsTo Web:PostText
Web:PostText ai:connectsTo Location:Lat
Accelerometer:Shaking ai:connectsTo Location:Lat
• Privacy description produced in Linked Data format (machine-‐readable) à HTML (human-‐readable)
15
“Source code” Analysis
Accelerometer:Shaking ai:connectsTo Web:PostText Web:PostText ai:connectsTo Location:Latitude Accelerometer:Shaking ai:connectsTo Location:Latitude
• Web:PostText was pre-‐deJined as “potentially data leaking”, hence the operations highlighted in red indicate where the user’s data may leak
16
“Source code” Analysis
Accelerometer:Shaking ai:connectsTo Web:PostText Web:PostText ai:connectsTo Location:Latitude Accelerometer:Shaking ai:connectsTo Location:Latitude
• Compiler packages HTML and Linked Data Jile into the downloaded apk • An Android menu option allows users to view the privacy description
17
Mobile Integration
• Basic online survey to get feedback on the existence of such a privacy framework
• Collected 31 responses from existing App Inventor users who have published mobile apps on the Google Play Store
• Results mostly positive: 74% said they would use it and that it would save them time
• Most comments on the aesthetics of the privacy description
18
Exploratory User Study
• Various reasons for choosing to not use PrivacyInformer, but perception of privacy descriptions is an obvious factor
19
Exploratory User Study
0%
5%
10%
15%
20%
25%
30%
35%
40%
Not important Of little
importance Moderately Important Important
Very important
Percentage of Respondents
Reaction to PrivacyInformer vs. perception of privacy description importance
Would Use PrivacyInformer Would NOT Use PrivacyInformer
• Most people thought writing a privacy description would take them between 1 to 2 hours without PrivacyInformer
• Less than 15 minutes with PrivacyInformer 20
Exploratory User Study
0
2
4
6
8
10
12
14
Less than 15 minutes
Between 15 minutes and 1
hour
Between 1 hour and 2 hours
Between 2 hours and 5 hours
More than 5 hours
Num
ber of Responses
Time spent making privacy document with and without using PrivacyInformer
Using PrivacyInformer Without PrivacyInformer
• Privacy policies are long because legal experts want to lower the risk of litigation by using general terms that open up room for interpretation.
• Any piece of public privacy statement included with a mobile app can become the basis for litigation. How to increase motivation for developers to use privacy statements? – Perhaps the law should create a “safe harbor” for mobile developers to present privacy statements in good faith. FTC could increase burden of proof, such that only deliberate attempts of privacy violations are penalized.
• One inJluential party in the mobile apps market is the app platform owner, such as Apple, Google etc. – Regulatory agencies could focus on managing these app platforms, rather than targeting the entire mobile app market.
– Machine-‐readable privacy documents generated by PrivacyInformer could be used at the app platform level to allow Jiltering by privacy preferences. 21
Policy Discussion
• PrivacyInformer opens up possibilities for various interesting extension work – Different presentation of privacy information – Mobile app matching based on privacy preferences – Generate privacy rules that govern data access, allowing accountability to data usage as well as collection and dissemination
• Privacy issues are only just emerging in the mobile market. PrivacyInformer tries to address one aspect of a bigger picture, with much more left to learn and explore. 22
Future Work & Summary
Thank You!
23
