# PerHelper: Helping Developers Make Better Decisions on Permission Uses in Android Apps
## 2 Background and Related Work
### Improving the Android Permission Model  
Many works have attempted to improve the Android permission model. These works can be divided into three categories:  
* _Modifying the current Android permission model._ For example, [PERSON] et al. [26] advocated to replace the _app-centric_ permission model with the original _resource-centric_ model, which provides more flexibility. Other approaches like Apex [27] propose a new policy enforcement framework for Android that allows a user to selectively grant permissions to apps.
* _Rewriting the apps_ to perform fine-grained permission access control. For example, [PERSON] et al. [28] inserted additional methods before the API methods that require a permission. Those added methods will check if users grant permission or not, and if not, the permission-related API methods will not be invoked. Similarly, [PERSON] et al. [29] used the same principle to perform fine-grained access control on third-party libraries.
* _Information flow-based fine-grained policy enforcement._ TaintDroid [30] is a representative work that tracked the sensitive data (taint source) flows during app execution at runtime. A numberof studies extended the system to track information flows. TISSA [31], MockDroid [32], and AppFence [33] propose to replace sensitive information with fake data. CleanOS [34] proposes to modify TaintDroid to enable secure deletion of information from application memory. Kynoid [35] extends TaintDroid with user-defined security policies such as restrictions on destination IP addresses to which data are released. [PERSON] et al. [36; 36] extended TaintDroid to enforce fine-grained access control based on the purpose of permission use in Android apps.
* _Crowdsourcing-based methods._ Some approaches [17; 37; 38] attempt to utilize crowdsourcing to recommend suitable permission settings for an app for different kinds of users. These methods are able to free the users from having to understand the mechanics behind permissions.  
As we can see, most existing methods deal with the issue from the user's perspective, without considering how developers can help during the process. Typically, these methods either need to modify and repackage the app or modify the Android framework or the operating system.  
The existing approaches face several important challenges:  
* Many approaches need to instrument and repackage apps if they want to modify their behaviors. However, repacking apps will not always succeed. Repackaging apps will change the signature of the original app, and if the app checks its signature for integrity, it will refuse to run. Actually, many popular apps (e.g., WeChat) have already applied runtime signature checks, and doing so will be more and more popular in the future.
* Modifying the Android platform, on the other hand, is also not practical and is potentially dangerous. Introducing new permission models or frameworks in practice must have a user either install a whole new system or run them on a rooted device, which will lead to security vulnerability [39; 40].
* Typically, mobile apps are the carriers of permission-related issues. However, no matter how hard we have tried to fix the issues after the apps are released, it is impossible to enforce a complete control on all instances of a particular app. We can only solve these issues completely at its very beginning or in the development phase of an app.