Privacy impact self-assessment app

(1)

Privacy impact self-assessment app

Ludwig Toresson

Sebastian Olars

Maher Shaker

Faculty of Health, Science and Technology

Department of Mathematics and Computer Science 15 HP

(2)

(3)

Abstract

The popularity of the Android OS has led to the development of millions of applications. The assumption of the majority of the An-droid user base is that these applications are trustworthy and that the Android system does enough to protect them from the untrustworthy applications. This assumption is however false as the Android system does allow trustworthy applications to track users in different ways and does nothing to detect and remove untrustworthy applications. This project aims at informing users about which of their installed applications is tracking them and all of the negative effects it can have on a persona that is similar to them. This is done through an application that uses a pre-filled log containing the data collection of different applications to match an application with negative effects on a specific predefined persona.

(4)

1 Introduction

People nowadays frequently use smartphone applications to assist them in their daily lives, by motivating them to exercise, to remember what to buy, to socialize, and to buy products. To allow many of these applications to function as well as to provide heightened levels of security, smartphones come with a wide variety of functionalities and sensors, like cameras, GPS, Bluetooth, WiFi access, accelero-meter, fingerprint recognition, face-scanners, microphones and many more. These functions are embedded into the hardware system of the smartphone, which means that if a user gives the application the corresponding permission the applic-ations can access/use the functionality. There does however exist problem with how the application is granted the permissions. Applications will at many times ask the user for a permission while never explaining the reason for why it wants it, and if the application is not granted the permission then it might stop function-ing [1]. This becomes complicated when the average user a.k.a. digital natives [2] will most likely not bother to check which permission the application asks for, and even if they do, they will most likely not understand the risks that it entails. There is also a lot of applications which have a tendency to start up and run in the background for the sake of collecting statistics, a decent amount of these will start during off-hours like when the user is asleep. During this startup time, the application is free to utilize any of its given permissions to collect user statistics and many a time they will access parts of the phone that they have nothing to do with like the user’s contact list [3].

There has been a growing concern in how to properly inform and educate digital natives of the risks and the manner in which their personal data is collected in a way that can be easily digested and understood. One of the more concerning ways user data can be used is with propaganda, the reasoning being that the more an adversary knows about individuals the easier it is to find a susceptible group and create a custom message that will have as much impact as possible. For proof of this one can look at the 2016 American election [4].

A persona is an abstract view of an individual, it is commonly used by companies when designing and creating new products. It is also widely used by researchers when making folk studies, the reasoning behind their usage is that it is a lot more complicated to make an accurate representation of all entities in a population than it is to create a generalised model of an individual which many people can associ-ate with. The persona in question, however, can of course not be so generic that everyone is included in it, nor so restrictive that almost no one is included in it as it then loses its purpose. There is also a growing usage of them in computer science as a means to predict user behaviour for the sake of finding potential security flaws and creating new services.

(7)

meth-ods used for the sake of objectively analyze situations for the sake of learning the likelihood that an unwanted event occurs. There are a lot of tools for allowing companies to easily perform PRA and PIA for finding security flaws with their products and investment. There are however very few tools for allowing individu-als to easily perform personal PIA:s for the sake of finding which risk they are exposed to from their own personal technology use. That service is what this ap-plication is looking to offer.

Research has found that the problem with the permission granting process does not lay in the interface the consumer uses to grant the application the specific per-mission. Rather the problem lays in the fact that there is not a good and intuitive way for users to learn about the potential security risks associated with granting the application the given permission. [5] [6] [7].

2 Project Setup

2.1 Initial Project Specification

The initial project description given to us was to design and implement a graphical user interface for an application that would be run on Android devices. The ap-plication is supposed to provide a self-assessment of the users installed apap-plications and their associated privacy impacts through their permission use.

The application will be examining the installed applications on the device in ques-tion and compare them to the statistical informaques-tion about the applicaques-tions that are stored in the KAUDROID database.

The self-assessment application is supposed to engage the user into a graphical interactive dialog about the following subjects:

• The application’s access to information used by the device

• Potential impact to the device owner if this information is misused

• The device owners preferred means of restricting the application’s data ac-cessibility

A user should be presented with the privacy risks which is harmful to a specific persona caused by certain aspects of data sharing.

(8)

After the assessment has been completed, the user will be presented with options of partial consent. These options can be for example Time boundary, delete-after-transaction, try-before-buy, ask me for permission for further processing, let me pay with money instead of personal data, etc.

Lastly, The application should collect the choices in the self-assessment and also the user’s choice of partial consent.

2.1.1 Previous Work

This project is a continuation of previous work that Karlstad University has done that focuses on the analyzation of the manner in which Android applications col-lect user’s data through the use of permissions. The ongoing research has been given the general name of KAUDROID, in the first phase the projects focus on data collection, their research results can be found in these articles, [8] [9] [10] [11]. The data collection was done through the creation of an application capable of de-tecting whenever another application used one of the permissions that they had been granted, it then logged that activity with a timestamp for when the event occurred. The data was then divided into a set called partial identify attributes, where each set contained a set of permission that corresponded to it. Examples of this would be Whereabouts that contained the permission of FINE LOCATION (1), CAMERA (14), ACCESS BLUETOOTH etc ( [10]).

This project looks to further this research by using the log files generated in the previous project for the sake of making a PIA(Privacy Impact Assessment) application designed for the usage of regular users.

3 Partial Identity Attribute

Partial Identities are constructed from sets of Attributes from one or more sources [10]. These attributes in question are derived from the Android OS permissions. Permissions are the legislative documentation allowing a certain application to use a specific function of the phone it is installed on. An application must docu-ment all permissions that it wants in its manifest file for the sake of making it as transparent as possible [1]. Permissions are classified in two groups Normal and Dangerous permissions. Normal allow the application to access resources outside the application’s sandbox, though Google deems that the access to these resources only poses a low risk for the user. Dangerous permission on the other hand allow the application to access resources outside of their sandbox, which Google thinks could be used to bring harm to the user.

(9)

These sets then provide a means to better visualize the way in which these permis-sions are used by an application to collect privacy information. For this project four partial identity attributes were used, those being Whereabouts, Social Graph, Network, and Biometric-Id.

3.1 Whereabouts

Whereabouts is a set that contains the different permissions which could be used to locate the phone on which the application is installed on. In this project where-abouts consist of the permission, MONITOR LOCATION (2), FINE LOCATION (1), COARSE LOCATION (5), GPS (6), MONITOR HIGH POWER LOCATION (8), CAMERA (14), WIFI SCAN (7).

3.2 Social Graph

Social Graph is the set which contains the permission that allows the application to access the users social information. This entails the users contact list, message logs (both SMS and call-logs), calendar and many much more. READ CONTACTS (11), READ SMS (13), READ CALL LOG (16), READ EXTERNAL STORAGE (4), OP READ PHONE STATE (3), GET ACCOUNTS (9), READ CALENDAR (10), RECEIVE SMS (17).

3.3 Network

Network is the set of permissions that allow the application to gatherer information about the networks that the phone connects to. An example of information this entails is MAC and IP-addresses. It consist of WIFI SCAN (7).

3.4 Biometric-Id

Biometric-Id is a set that contains the permission which allows the application to gather the user’s biometric information. Things like fingerprints, health data, fitness data, and photos. It consist of USE FINGERPRINT (12), CAMERA (14), RECORD AUDIO (15).

3.5 Permission

(10)

that the OS will automatically grant the application on requesting them. While Dangerous permission on the other hand are the ones that the OS deems poten-tially problematic if granted to the wrong application making it so that it is only the users that can grant them to the application. Applications of API level 22 and below will only ask for the permission of a specific function during its initial installation. Applications of API level 23 and above will not ask for permissions classified as Dangerous before the first time they use them, in both of these cases however after a permission is granted the application will assume that it always has it. This can cause a problem as a user might not fully understand the rami-fication of giving an application a certain permission [3].

Here is a list of the permission commonly found on an Android phone with an explanation:

1. FINE LOCATION

• Allows an application to access the phone’s precise location 2. MONITOR LOCATION

• Allows the application to continually monitoring location data 3. OP READ PHONE STATE

• Allow an application to access phone state related information 4. READ EXTERNAL STORAGE

• Allows an application to read from external storage, a.k.a. accessing files outside of sandbox.

5. COARSE LOCATION

• Allows an application to access the phone’s approximate location. 6. GPS

• REPLACED WITH ACCESS FINE/COARSE LOCATION 7. WIFI SCAN

• Allows the application to identify the available WIFI spots 8. MONITOR HIGH POWER LOCATION

• Allows the application to continually monitoring location data with a relatively high power request

(11)

• Allows the application access to the list of accounts in the Accounts Service

10. READ CALENDAR

• Allows an application to read the user’s calendar data, this includes any notes of events for specific dates.

11. READ CONTACTS

• Allows an application to read the user’s contacts data 12. USE FINGERPRINT

• Allows an application to use fingerprint hardware 13. READ SMS

• Allows an application to read SMS messages 14. CAMERA

• Allows an application to enforce the uses-feature manifest element for all camera features. If you do not require all camera features or can properly operate if a camera is not available, then you must modify your manifest as appropriate in order to install on devices that don’t support all camera features.

15. RECORD AUDIO

• Allows an application to record audio 16. READ CALL LOG

• Allows an application to read the user’s call log 17. RECEIVE SMS

(12)

4 Personas & Threats to Anonymity

4.1 User Personas

User personas as shortly described in the introduction can be used as a way to as-sociate a persona with the abstraction model of an individual. As described in [15] it is very important when it comes to security to be extremely specific for different population’s concerns. The different user groups will have different characteristics and needs in relation to privacy and security. A well-constructed user persona can be used as a profile for a hypothetical user which describes a summary of data from multiple users with similar concerns.

User personas can be used for developers of applications to think about differ-ent individual’s concerns when using an application. There may be more users that are more vulnerable than others. These people can be part of specific vul-nerable groups like the LGBTQI population, journalists, activists, politicians, etc. Depending on the user persona there are different needs for security, privacy, and ability to access the internet.

4.2 Privacy Personas

In contrast to user personas a privacy persona can be explained as an abstract grouping of multiple user personas. They define a broader privacy concern for a group of personas. Some of the more famous privacy personas are the ones defined by Alan Westin. These categories are known as the marginally concerned, the fundamentalist and the pragmatic. Where the marginally concerned give a mixed view of privacy concerns while pragmatics has little to no concerns and fundamentalist has very large privacy concerns [16].

Later newer categories have been defined to separate more specific groups of per-sonas [2] from the more general categories. In these categories, the perper-sonas are dependent on multiple factors. They depend on the trust of security technolo-gies, concerns for others, convenience, etc. All of these are widely dependent on a personas knowledge and motivation for concerning themselves with privacy.

4.3 Personas

(13)

done to categorise the different personas and also be able to generate threats and vulnerabilities specific to the personas.

4.3.1 Background

Each created persona will contain a short background story which in short sen-tences explain personal traits. These traits can be gender, age, profession, personal health, relationships, etc.

4.3.2 Technology Expertise Level

The level to which a person has knowledge about technology. Personas have a different background which most likely leads people being exposed to technology in different ways. People have different knowledge and thoughts of their own personal privacy, as-well-as knowledge about security practices on the internet.

4.3.3 Technology Use

The technology use explains in what way a persona uses a device and the internet, and for what purposes. Some personas might use it to connect with friends and family. Some use it to make normal daily tasks easier, such as banking and work-related tasks.

4.3.4 Access Location

The access location for personas explains where a persona uses technology in their normal lives. Possible locations where personas might use technology to access the internet could differ in security. Public internet access at a restaurant might not have the same security as your private work internet.

4.3.5 Threats From Technology Use

(14)

4.3.6 Vulnerabilities

Each persona has a different background that makes it more or less exposed to specific vulnerabilities. A vulnerability to a persona can be presented through multiple different uses of technology. Examples of vulnerabilities could be location tracking, personal relationships, disease.

4.3.7 Needs

Depending on an individual’s background they will have different needs. These needs can, for example, be the need to keep vulnerable biometric data private, like an illness. It can also be related to security, like being anonymous on the internet or keeping personal information secured on a device.

4.4 Used Personas

The following personas will be used in the application for users to choose between. A user will read through all of the information of a persona and select the one that the user feels closest to themselves.

An example of such a persona description is presented below in figure 1. For a full and detailed list of the personas used in the project go to Appendix C.

(15)

Figure 2: Information about the persona Carl G¨oransson

4.5 Mapping : Personas & Permissions

(16)

Figure 3: fig: A diagram showing the manner in which permissions and personas has been mapped

If one would want an example for a more detailed look of this connection, look at figure 4. In this figure one can clearly see how the threats of a specific persona relates to the Partial Identity Attributes.

The full black arrows in 4 symbolizes a clear connection between the threat and Partial Identity Attributes, while the dashed arrows depicts a weak connection. The consequence column shows the level of severity associated with a specific im-pact, and impacts are the actual events that can happen to the persona.

(17)

Figure 4: Carl G¨orransson Map

5 Tools

For the development of this application mainly Android Studio was used as the de-velopment API in combination with the programming language Java, and REALM for the database, though python was also used for the sake of filtering useful data from the KAUDROID database.

5.1 Android Studio

Android Studio is a development API developed by Google for the development of applications for Android devices. It offers two languages to work with, Java and Kotlin while also offering common API support as debug mode and compatibility with user-created libraries. The API also provides the user with an easy to use graphical design interface with XML support.

5.2 Java

Java is a general-purpose, object oriented, class based programming language, built upon the idea of write once work anywhere (WORA). It is one of the currently widely used programming languages in the world, in large part to the Java Virtual Machine (JVM) which allows the applications to be run on a platform that the JVM support without having to do any changes to the code. [17]

(18)

5.3 Python

Python is a great programming language and one of the most famous programming languages currently. It is also known as one of the best scripting-languages with extensive libraries for string manipulation. In this project, Python was used to unpack the log-files which were in JSON-format. The necessary data was then collected and packed into a JSON-format again to be used for the application.

5.4 REALM

REALM is an open-source, object-based database management system. Being object-based means that instead of storing the relation of data as in SQL, REALM takes and stores an entire data-struct as data in the database. This means that REALM is language-specific as the objects are dependent on the design convention of a class.

6 Design

Android Studio was chosen as our IDE as it offered a lot of functionalities for mak-ing the development of applications easier. Java was chosen as the programmmak-ing language as the entire team has had previous experience with the programming language. The database management system REALM was chosen for its easy in-tegration with Android application development. REALM was also chosen because of how the structure of a REALM object-based database fits perfectly with the planned structure of the different data that the application stores.

6.1 Data preparation

The project group was given multiple log-files in the JSON-format from the KAUDROID database. Each object in the JSON-file contained a single permission access. The structure of each permission access contains the following:

• Phone ID: Corresponding to the phone at which the permission access was captured

• Application package: The name of the application package for the applica-tion that performed the permission access

• Permission: The name of the Android permission request

(19)

• GPS: Location at which the permission access took place • Synced: Flag for synced

An example of such an object could look like the following figure.

Figure 5: Example of a logged permission from the KAUDROID database

All of these fields were not necessary for our application to work effectively. This is why the JSON-files were run through a script to collect valuable data in the file. The script was written in python and it created a new object structure for each ap-plication package found in the JSON-files. Each package structure contains names of the four separate permission categories(whereabouts, bio-metric ID, network ID, and social graph). In each of the categories, multiple key-value pairs were created for all of the collected permissions. The key described the permission name or more specifically the permission request, while the value describes the number of times the application package requested that permission.

An example of such an object could look like the following figure.

Figure 6: Example of the final package object structure

6.2 Database Design

For our application, we decided to use the REALM database for the storing of our offline data. REALM is a database that offers support and easy integration with Android Studio.

(20)

that have different fields of different types, thinking that there is an object called AppModel that is initialized for each new application and stored in a parent object called AppsModel makes it much easier to understand the structure of the data and thus much easier to handle the data.

Another big factor that influenced the choice of a database was the speed, speed is one of the major attributes that affect the user experience. REALM database is one of the fastest database currently available [18] [19] .

The database for this project is divided into three different database files, data, persona and log.

The data file contains all the necessary information regarding the logged applic-ations. Such information could be identity attributes and which permissions are used in those identity attributes.

The persona file contains all the necessary information regarding the different generated personas. Such information could be the weaknesses of the personas and threats that could affect the personas based on the weaknesses.

The log file contains ephemeral information pertaining to the steps taken in the application and the data generated by those steps. Such information could be the application chosen by the self-assessment process or the persona chosen by the user.

6.2.1 Data File Structure

(21)

Figure 7: Data Model Diagram

6.2.2 Persona File Structure

The persona database file is structured the same way as the data file in that the objects in the file call each other in a hierarchic manner.

(22)

Figure 8: Persona Model Diagram

6.2.3 Log File Structure

The main reason for having the log file is because it is important to store all the different paths and choices that are traversed and chosen for future research and improvement of the application and the processes inside the application.

(23)

Figure 9: Log File Structure

6.3 Programming Design

When developing the self-assessment application, the team tried to develop it according to the SOLID design principles. Both for the sake of making the de-velopment of the application easier while also reducing potential accumulation of the technological debt.

6.4 GUI Design

(24)

Figure 10: Middle part of the application

(25)

Figure 12: Opening part of the application

As one can see by comparing the flowchart to the images found in the Application Run Through the project has, for the most part, followed the initial design. The big deviations are that the persona info-screen 16b was added afterward and that the persona quiz is missing. The quiz would have allowed the users to know which one of the personas corresponds to them the most. The purpose is that it would allow the user to get an outside opinion for the decision as they might otherwise subconsciously be drawn to or pushed away from a specific persona.

The idea was scrapped for a lack of time but is something that could be revisited in a future project.

6.5 Log File Design

A log file feature for the self-assessment application was one of the last parts that were implemented and one of the more important features of the application. The purpose of the log file is to log all of the information collected by the application at the end of the self-assessment. It will log all of the choices the application user has made and also all of the choices the application has made.

(26)

We didn’t want to ask the application user for permission access right at the start of self-assessment. Due to this, the application and user decisions had to be transported through the application, to the logging feature in the mitigation activity. At first, all of the decisions were sent with the intent to each of the activities in the application. This was later changed because it didn’t seem to be a maintainable way of doing it, which is why a new log file structure was created in the database. With this implementation, each decision was stored in the database for later use when writing to the file.

The write operation to the log file is executed when the application user clicks the submit button on the mitigation screen. At that point, the permission access will be check and if it is not yet accepted by the user, a request will be sent. If the permission is accepted, all of the information from the database log file structure will be collected and the user’s final mitigation choice will be written to the log file.

The user of the application has the possibility to log the decisions one time for each self-assessment, this to keep the information in the log file more accurate. Each logging instance of the self-assessment application includes the following:

• Timestamp: The time and date at which the self-assessment was completed • Persona: The persona selected by the application user during the persona

selection

• Package: The name of the application package for the selected application • Partial identity attribute: In other words, the category to which the

permis-sion belongs

• Permission: The name of the permission that the application accesses • Vulnerability: The vulnerability that was presented to the user

• Mitigation: The mitigation technique that the application decided upon at the end of the self-assessment

An example of a self-assessment log is shown in (13).

(27)

7 Implementation

7.1 Classes

The project is mainly done in an object-oriented manner meaning that the code is contained in namespaces that in turn contain classes. Examples of classes are: the different GUI interfaces(figure 25 in appendix) called activities, the database class that manages the database, and all other classes that handle the back-end part of the application. The most important class in the application is the class that handles all the matching and decision making in the application. That class is called StartUpSelection(figure 24 in appendix) and handles all of the decision making from start until the mitigation screen. Some of the main responsibilities that it has are: selecting an application at the start, choosing personas based on the chosen application, and choosing a vulnerability based on the chosen persona.

7.2 GUI elements

The most notable GUI features of this project are the swiping functionalities. One of them being the swipe adapter implemented for the persona view, which makes it possible to swipe between personas. The swipe adapter works by increasing an integer by 1 if the swipe is to the left and decreasing it by 1 if the swipe is to the right. The persona that is supposed to be shown is determined by using modulus with the number of personas and that integer, and then fetching that persona from a list of personas.

The other swiping feature in this project is an upward swipe from the persona view, which will open the information page of the currently viewed persona. This feature was implemented using coordinates, meaning the coordinate where the finger touched the screen and the coordinate at which the finger left the screen. If the coordinate at which the finger leaves the screen is greater than the coordinate at which the finger touched the screen, then it is determined that the swipe was upwards.

8 Application Run Through

8.1 Main Startup Screen

(28)

corner of the screen, a progress bar is displayed showing the number of the current screen that is shown.

8.2 Application Selection Screen

The application selection screen in figure 14(b) will display the application that was selected for the self-assessment. This application will be an application that is present in the log-file from the KAUDROID database and in the currently used Android device. The self-assessment application will prioritize to select a user-installed application before a system application.

(a) Initial Activity Screen (b) Start Activity Screen

(29)

8.3 Context Screen

In the context screens displayed in figure 15 the individual using the self-assessment application will be presented with the context of the application. The context will describe what each of the following parts of the application will ask from the individual.

(a) Main context screen (b) Context pop-up screen

Figure 15: Context screens

8.4 Persona Screen

(30)

(a) Persona selection screen (b) Persona info screen

(31)

8.5 Vulnerability Screen

In the vulnerability screen displayed in 17(a) the selected persona will be shown together with a vulnerability. This vulnerability is a random vulnerability from the persona that matches the partial identity attribute of the persona and the application that was selected. Besides the persona image, an additional image is displayed on the vulnerability page which corresponds to a specific partial identity attribute. For example in 17(a) at the bottom of the screen the image correspond-ing to ”social graph” is shown. It illustrates a persona in the middle with a cluster of connecting persona around it. It is supposed to describe all of the personal connection an individual can have on the internet.

8.6 Mitigation Screen

(32)

(a) Vulnerability screen (b) Mitigation screen

Figure 17: Vulnerability and mitigation screens

9 Testing : Process and Results

9.1 Process

Tests were done by asking people to install and run the application on their own phones. Users were asked to run the application multiple times for the sake of testing out the different scenarios. They were then asked for their feedback on the application, in regards to what felt clunky, and what was unclear/confusing.

9.2 Results

(33)

different applications that will show up for the self-assessment. For example, a person with many installed applications will most likely get a more varying self-assessment every time the application is started. This is because the applications that show up, have to both be installed on the device, as-well-as be presented in the log file that is used by our self-assessment application.

10 Contributions

10.1 Application Development

10.1.1 Ludwig Toresson

• Log file script

• Persona swiping mechanism • Logging of self-assessment

10.1.2 Maher Shaker

• Persona information swiping mechanism • Database integration

• Some GUI elements

10.1.3 Sebastian Olars

• Code skeleton • Some GUI elements

• Front-to-Back-end communication

10.2 Report Writing

10.2.1 Ludwig Toresson

(34)

• Log file design

• Application run through • Planning • Future work • GUI Elements 10.2.2 Maher Shaker • Abstract • Personas • REALM • Database Design • Self Assessment • Classes 10.2.3 Sebastian Olars • Introduction

• Partial Identity Attribute • Tools

• Testing • Contribution • Planning

• Mapping: Personas Permissions

11 Planning

(35)

In the initial- and definition phase there was not any programming involved and most of the time was spent reading background material and developing a system specification and design. Each week a task was given to the group to complete for the coming week. This was for example at the start of the project to discuss and create general personas that could be used in the application.

(36)

11.1 Self Assessment

What was achieved

The application was completed with a set of different personas, the ability to log the choices from a run, and the ability to easily add more information to the data-base in the form of data-files. A user friendly GUI was designed to keep the users interest during the whole self-assessment process. A smart game-flow was also implemented which correlates personas vulnerabilities to applications permission uses.

What problems came up

A significant part of the implementation phase was spent on learning how to work with the API, Android Studio, and the REALM database.

As a part of the problems with the learning phase was the matter of saving the state of the application and then transfer that information to the next step of the application.

How well were the specifications followed

The group was able to complete all items found in the Initial Project Specific-ation, excluding the additional task of adding multi-dimensional interfaces for the user.

12 Conclusion

In this paper, we introduce the implementation and design of the self-assessment application. This application is meant to, in a fast and easy way, get individuals more aware of the potential privacy risks that various installed applications can pose.

In this project, a complete evaluation of the application is missing, where the ap-plication should be tested by many different individuals to see if the self-assessment contributes to more privacy-awareness of applications.

13 Future Work

There are a few tasks that could be added to our implementation to further improve the application:

(37)

new persona to the database file. They would have to add background info, name, vulnerabilities, etc to create a complete persona. There are also a few parts of the implementation that is static for the personas, like pictures, which would also have to be added manually. This database file will then have to be reloaded into the assets folder and added to the realm database. As future work, this process could be made easier by adding a feature to the application which makes it possible to add new personas. It may be an extra view in the GUI that automatically generates a persona or fields for the user/developer to add the persona information to.

• Impact level: There is currently no use of the level to which an application uses a permission. The level, which is the number of times an applica-tion uses a specific permission. This is represented by an integer in ”json-Dump.json”, which gets loaded into the realm database. For future work, this level should be taken into account by our application. There may be some visual indicator showing the user how often an application uses the permission.

• Persona Quiz: A quiz could be implemented for users that are unsure which persona corresponds the most to them. The quiz would ask the user a set of questions and through the results would then tell the users in percentage how much they correspond to a persona.

References

[1] Android documentation, permissions overview. https://developer. android.com/guide/topics/permissions/overview. Accessed: 2019-12-03.

[2] Janna Lynn Dupree, Richard Devries, Daniel M Berry, and Edward Lank. Privacy personas: Clustering users via attitudes and behaviors toward secur-ity practices. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, pages 5228–5239. ACM, 2016.

[3] Majid Hatamian, Nurul Momen, Lothar Fritsch, and Kai Rannenberg. A multilateral privacy impact analysis method for android apps. In Annual Privacy Forum, pages 87–106. Springer, 2019.

[4] Carole Cadwalladr and Emma Graham-Harrison. Revealed: 50 million face-book profiles harvested for cambridge analytica in major data breach. Sat, 17:22–03, 2018.

(38)

related decisions. Journal of Information Security and Applications, 34:8–26, 2017.

[6] Patrick Gage Kelley, Lorrie Faith Cranor, and Norman Sadeh. Privacy as part of the app decision-making process. In Proceedings of the SIGCHI conference on human factors in computing systems, pages 3393–3402. ACM, 2013. [7] Lydia Kraus, Ina Wechsung, and Sebastian M¨oller. Using statistical

inform-ation to communicate android permission risks to users. In 2014 Workshop on Socio-Technical Aspects in Security and Trust, pages 48–55. IEEE, 2014. [8] Nurul Momen, Tobias Pulls, Lothar Fritsch, and Stefan Lindskog. How much

privilege does an app need? investigating resource usage of android apps (short paper). In 2017 15th Annual Conference on Privacy, Security and Trust (PST), pages 268–2685. IEEE, 2017.

[9] Nurul Momen. Turning the table around: Monitoring app behavior. SICH-ERHEIT 2018, 2018.

[10] Lothar Fritsch and Nurul Momen. Derived partial identities generated from app permissions. Open Identity Summit 2017, 2017.

[11] Adrian Carlsson, Christian Pedersen, Fredrik Persson, and Gustaf S¨oderlund. KAUDroid: A tool that will spy on applications and how they spy on their users. Karlstads universitet, 2018.

[12] Android documentation, permissions overview. https://developer. android.com/reference/android/Manifest.permission#GET_ACCOUNTS. Accessed: 2019-12-03.

[13] Android documentation, permissions overview. https://developer. android.com/reference/android/app/AppOpsManager. Accessed: 2019-12-03.

[14] Android documentation, permissions overview. https://developer. android.com/guide/topics/connectivity/wifi-scan. Accessed: 2019-12-03.

[15] User personas for privacy and security. https://medium.com/@gusandrews/ user-personas-for-privacy-and-security-a8b35ae5a63b. Accessed: 2019-10-29.

[16] Ponnurangam Kumaraguru and Lorrie Faith Cranor. Privacy indexes: a sur-vey of westin’s studies. 2005.

(39)

[18] Taichino. Performance comparison of realm and sqlite on ios, Mar 2017. Accessed: 2019-12-08.

(40)

A

Persona Threat Mapping Graphs

Figure 19: Carl G¨orransson Map

(41)

Figure 21: Lina Odinsson map

(42)

(43)

B

UML Diagrams

(44)

Figure 25: UML diagram for rest of the activities

(45)

Figure 27: UML diagram for Persona

(46)

C

Detailed Persona Descriptions

(47)

(48)

(49)

(50)

Privacy impact self-assessment app