Dude, Ask The Experts!: Android Resource AccessPermission Recommendation with RecDroidBahman RashidiCarol FungDepartment of Computer ScienceVirginia Commonwealth UniversityRichmond, VA, USA{rashidib, cfung}@vcu.eduAbstract—With the exponential growth of smartphone apps,it is prohibitive for apps market places, such as Google App Storefor example, to thoroughly verify if an app is legitimate or malicious. As a result, mobile users are left to decide for themselveswhether an app is safe to use. Even worse, recent studies haveshown that most apps in markets request to collect data irrelevantto the main functions of the apps, which could cause leaking ofprivate information or inefficient use of mobile resources. Toassist users to make a right decision as for whether a permissionrequest should be accepted, we propose RecDroid. RecDroid isa crowdsourcing recommendation framework that collects apps’permission requests and users’ permission responses, from whicha ranking algorithm is used to evaluate the expertise level ofusers and a voting algorithm is used to compute an appropriateresponse to the permission request (accept or reject). To bootstrapthe recommendation system, RecDroid relies on a small set ofseed expert users that could make reliable recommendationsfor a small set of application. Our evaluation results show thatRecDroid can provide high accuracy and satisfying coverage withcareful selection of parameters. The results also show that a smallcoverage from seed experts is sufficient for RecDroid to cover themajority of the app requests.I.I NTRODUCTIONFirst introduced in 2008, Android has gained a tremendousmomentum over the last few years. According to Gartner [3],a technology research and advisory firm, 1.1 billion devicesrunning Google’s Android OS will be shipped in 2014 alone,marking its 80 percent mobile market share. Attributing to thisfast-pace increase is the proliferation of Android apps, whichprovides an ever-growing application ecosystem. Officiallyreported by Android Google Play Store, the number of apps inthe store has reached 1 billion, surpassing its major competitorApple Apps Store in late 2013 [42], and predicted to reach1.5 billion apps by the end of 2014. The market offers a widerange of applications from entertainment, productivity, throughhealth care and even the highly sensitive ones such as onlinedating, home security, business management, to mention a few.As users more and more depend on mobile devices andapplications, the privacy and security concerns become moreimportant. For example, a malicious third-party app can notonly steal private information, such as contact list, text messages, and location from its user, but can also cause financialloss of the users by making secretive premium-rate phone callsand text messages [39]. At the same time, the rapid growth ofthe number of applications on Android markets makes it hardfor app market places, such as Google App Store for example,978-3-901882-76-0 @2015 IFIPTam VuDepartment of Computer Science and EngineeringUniversity of Colorado DenverDenver, CO, [email protected] thoroughly verify if an app is legitimate or malicious. As aresult, mobile users are left to decide for themselves whetheran app is safe to use.In current Android architecture, users decide what resourceis given to application at installation. Between applications,Android prevents malicious apps from unauthorized accessto other apps’ resource by isolating resources controlled byeach app. In the current setting, users have to grant allresource access requests before installing and using an app.This permission control mechanism, however, has been provenineffective to protect users privacy and resource from maliciousapps. Study shows that more than 70% of smart phone appsrequest to collect data irrelevant to the main function of theapp [2]. When installing a new app, a very small portionof users pay attention to the resource being requested, sincethey tend to rush through prompted permission request screensto get to use the application. Only a small portion (3%) ofusers pay attention and make correct answers to permissiongranting questions. In addition, the current Android permission warnings do not help most users make correct securitydecisions [19].Realizing these shortcomings in the current Android architecture, much efforts have been put towards addressing theproblems. Many resource management systems are proposedsuch as in [34], [37], [30]. Going deeper to the system level,L4Android [27] and Cells citecells isolate smart phone OSesfor different usage environments in different virtual machines(VMs). QUIRE [13] proposes a set of extensions addresses aform of attack, called resource confused deputy attacks, inAndroid. However, such approaches are not efficient sinceusers are either not paying attention to permissions beingrequested or not aware of the the permissions’ implications.Hence, no mechanism that assumes high technical and securityknowledge of users will be usable for a wide audience.As pointed out in [18], [17], the reasons for the ineffectiveness of the current permission control system include:(1) inexperienced users do not realize resource requests areirrelevant and will compromise their privacy, (2) users havethe urge to use the app and may be obliged to exchangetheir privacy for using the app. Because of that, to helpinexperienced users who want to protect their privacy fromuntrusted apps, we propose a novel solution to assist users inmaking informed decision in permission control while keepingtheir required level of attention at minimum. We propose aparticipatory framework that leverages permission responses296

from experts and peer users to suggest other users on how toresponse to a permission requests.are either not paying attention to permissions being requestedor not aware of the the permissions’ implications.In particular, we provide a framework, called RecDroid, toimprove and assist mobile users to control of their resourceand privacy through crowd sourcing. First, the frameworkallows users to use apps without giving all permissions andreceive help from expert users when permission requestsappear. RecDroid allows users to install untrusted apps undera “probation" mode, while the trusted ones are installed innormal “trusted” mode. In probation mode, users make realtime resource granting decisions when apps are running. Theframework also facilitate user-help-user environment, whereexpert users’ decisions are recommended to inexperiencedusers. The framework provides the following functionalities:Based on the existing centralized market places (e.g.,Android Market), Gilbert et. al. proposed AppInspector, anautomated security testing and validation system [21]. Thesystem is run by the market places or a third party to proveor disprove security properties of apps. However, they rely ona single party to perform the entire process including trackingsensitive information flow, identifying security and privacyrisks, and reporting potential risks of information misuse.Therefore, AppInspector does not scale well with app base.As a result, malicious apps are prosperous in the market. Two app installation modes for apps that is about to beinstalled: trusted mode and probation mode. In probationmode, at run time, an app has to request permissionfrom users to access sensitive resources (e.g. GPS traces,contact information, friend list) when the resource isneeded. In trusted mode, the app is fully trusted and allpermissions are all granted. An architecture to intercept and collect apps’ permissionrequests and responses, from which recommendations aremade as for what permission from which apps should andshould not be granted. A recommendation system to guide users with permissiongranting decisions, by serving users with recommendations from expert users on the same apps. A user-based ranking algorithm to rank security risks ofmobile apps.To the best of our knowledge, this is the first frameworkto (1) guide users to decide on which permissions should begranted by providing low-risk recommendations from expertusers, and (2) use optional probation installation mode, inwhich which permission requests are adaptively promptedto users which potentially improves the usability of thepermission-granting mechanisms, (3) allows market places toranking their app based on their security and privacy ratingthat is implicitly submitted by users. We thoroughly evaluateour proposed algorithms through simulations.II.R ELATED W ORKDue to its inherent constrains in resources, much efforthas been done towards the principles and practices to manageresource usage [34], [37], [30], [12], [20], [29], [7], [36] andprivacy protection [23], of mobile applications. However, themost common practice for resource access management todayis Mandatory Access Control (MAC) mechanism [16], [41],which is found in API from major mobile players such asApple iOS, Android, BlackBerry, and Windows Phone. Insuch paradigm, resource access from apps needs to be grantedby users. In Android, for example, this is done through itsstatic permission model [24], where users need to grant allrequested permissions on installation. Once the permissionsare granted by users, they cannot be revoked unless the application is uninstalled. Anderson et. al. studied the economicalimplications of this model across different application marketplaces and platform [4]. Studies [18], [17] have shown thatsuch permission control paradigms are not efficient since usersTaintDroid [14] and DroidChecker [11] are data flowtracking systems which allow users to track and analyzeflows of sensitive data and potentially identify suspiciousapps. TainDroid provides a tool for expert users to discoverpotential app misbehaving, while our system can effectivelyutilize responses from expert users and help other users protecttheir privacy through recommending appropriate permissiongranting decisions.Among the most related work, Kirin [15] proposes toidentify potentially malicious apps at installing time by lookingat the security configuration bundled with an application tobe installed. If predefined patterns are found, Kirin blocksand prevents the app from being installed. This approach israther conservative and heavily depends on the predefined setof security rules, making it not scalable. Revising the currentAndroid frameworks and/or runtime to provide fine-grainedresource controls, Apex [35], AppFence [25], MockDroid [8],and TISSA [1] avoid giving out sensitive data by grantingfake permission. While such approaches reduce the risk ofleaking private information and critical resources, it requiresusers to make decisions on every resource request, whichis difficult for inexperienced users and time consuming forothers. To make it easier for users to control their resources,AppGuards [6], Aurasium [43], and FireDroid [40] allowusers to define security policies on untrusted Android appson which the policies are enforced through their framework.In FireDroid, an application monitor is created to track allprocesses spawned in Android and allow/deny them based onhuman managed policies. This approach requires rooting thedevice and extracting the Android booting partition, whichis not practical for most users. In addition, the policy fileediting and management are also not user friendly for mostnon-savvy users. Therefore, FireDroid targets on corporationphone users where the FireDroid can be pre-installed andpolicies are managed by administrators. Similarly, AppGuardsand AurasiumThese require users to define a security policieswhich is not necessarily doable by inexperienced users. [22],[26], [28], [31], [32], [33] are proposed to rank, detect, andverify privacy risk and resource leakage of mobile apps.Crowdroid [10] and DroidChecker [11] propose a centralizedapproach to collect data traces from users and then analyzethem to classify malware from legitimate apps. This is acomplement approach to our except that RecDroid assists usersat fine-grained permission level instead of at application level.Going deeper to the system level, L4Android [27] andCells citecells isolate smart phone OSes for different usageenvironments in different virtual machines (VMs). QUIRE [13]proposes a set of extensions addresses a form of attack, called2015 IFIP/IEEE International Symposium on Integrated Network Management (IM2015)297

Apps Ranksx x x x Market PlacesAppsPermissionPi ControlControlPortalControlPortalPortalThin PortalOSThinPatch OSThin OSPatchPatchBad Response FilteringSeed/Savvy Users SearchResponse RecommendationApps RankingRecDroid ServicePermission responses App ID, PerReq, Response Permission responseRecommendationsMobile ClientsFig. 1.RecDroid Service Overviewresource confused deputy attacks, in Android. To facilitate that,recently, ASF [5] proposes a security framework with API thatallows authors of Android security extensions to develop theirown modules. TrustDroid [9] allows applications to be ran atdifferent trust levels (e.g. private vs. corporate). While theseapproaches are very useful in levitating vulnerabilities at system level, it does not help end-users to make a safer permissiongranting decisions. In contrast, our proposed approach promptsusers adaptively based on the collective permission decisionsfrom other users, and assists users in making decision throughRecDroid recommendation system.III.S YSTEM D ESIGNOur general approach is to build RecDroid with four functional processes, of which two are on mobile clients and theremaining two are on remote servers. In particular, RecDroid(1) collects users permission-request responses, (2) analysesthe responses to eliminate untruthful and bias responses, (3)suggests other users with low-risk responses to permissionrequests, and (4) ranks apps based on their security and privacyrisk level inferred from users’ responses. Figure 1 showsan overview of RecDroid service, which is composed of athin OS patch allowing mobile clients to automatically reportusers responses to and receive permission request responsesuggestions from a RecDroid service.Before going into further details about individual components, we first describe the permission handling procedureduring an installation a mobile app with RecDroid. Whena user first downloads and installs an application from appstores, the installer requests permission to access resources onthe device. Instead of being sent to the operating system’slegacy permission handler (e.g. Package Manager Serviceon Android) , the requests pass through RecDroid checks,which are installed on the mobile client at OS level. Figure2 illustrates the permission checking and granting flow onRecDroid. In the first installation of an app, RecDroid allowsthe app to be installed on one of the two modes: Trustedand Probation (tracking mode), as shown in Figure 7(a). Allrequested permissions will be permanently granted to the appas specified by the user, if Trusted mode was selected. Otherwise, in Probation mode, RecDroid will compare the requested298permissions against a predefined list of critical permissions thatis of concern to users, such as location access, contact access,and messaging functions, etc. Regarding the installation modeselection, RecDroid also recommends an installation mode tothe users based on collected data. For example, for new appsand apps that frequently receive rejections on permission requests, a probation installation mode should be recommendedto users. With critical permissions, RecDroid client queriesthe online RecDroid service to get response recommendationsfor the permissions, specifically for the apps to be installed.Upon receiving the answer from the recommendation service,RecDroid client pops up a request, combined with the suggested response, to the user, as shown in Figure 7(c). Basedon the suggested response, the user decide to grant or denypermission to access to certain resource. If a user chooses todeny a request, a dummy data or null will be returned to theapplication. For example, a denied GPS location request couldbe responded with a random location. That decision is bothrecorded in RecDroid client and populated back to RecDroidserver for app ranking and analysis. Only then, the request isforwarded to legacy permission handler for book keeping andminimizing RecDroid’s unexpected impact on legacy apps. Itis important to note that this process only happens once, whenthe app is first installed. Later, after collecting users responsesand preferences; and having a security and privacy ranking ofthe app, RecDroid server should decide and notify RecDroidclient whether to pop up permission requests or automaticallyanswer them based on prior knowledge. Therefore, RecDroidstrives to achieve a balance between the fine-grained controland the usability of the system. In order to realize RecDroidservice, four main challenges need to be addressed. When to suggest user to put an app into a probation mode?Leaving that decision to be decided solely by a user isnot a viable option because most users assume an app islegitimate and benevolent when they download. How do we instrument the operating system to interceptresource requests with the minimum amount of changes tothe system such that it does not affect normal and legacyoperations of the device? At the same time, how do wemake that instrumentation work on both existing legacyapps and coming apps? Given that the responses from users are subjective, couldbe bias, and even malicious, how do we design therecommendation and ranking system based that coulddetect and then filter out untruthful or bias responses? How do we bootstrap and expand the recommendationsystem? Since this is a participatory service, it is important to have a sustainable and scalable approach that couldprovide valuable recommendations to all applications. Itis certainly a challenging mission given millions of appsout there on different apps market places, and more tocome.At a high level, we propose a participatory framework tocollect and analyze users’ response to provide recommendations to users and rank apps based on the plausibility of theirpermission requests. In our proposed system, a PermissionControl Portal installed on the mobile devices intercepts apps’permission requests, records the requests, and collect users’response to the requests.Probation mode vs. Trusted mode The very first task of2015 IFIP/IEEE International Symposium on Integrated Network Management (IM2015)

nature as the spanning algorithm described in [38], RecDroidspanning algorithm is sketched as follow.IV.R EC D ROID R ECOMMENDATION S YSTEM D ESIGNIn RecDroid, the responses to permission requests from allusers are logged by a central server and they can be used togenerate recommendation to un-savvy users to help them makeright decisions to avoid unnecessary permission granting. Forexample, if a restaurant finding app is requesting for accessto the users camera, then the request is suspicious and verylikely will be declined by an expert user. The responses ofexpert users are then aggregated and the system would suggestother users of the same app not to accept the similar requests.However, how to find expert users and how to aggregate theresponses from expert users are the focus of this section.A. Rank RecDroid Expert UsersFig. 2.Permission request flow in RecDroidRecDroid is to decide whether to suggest an app to be installedin probation mode or in trusted mode. From metadata of theapp, RecDroid identify the category to which the app belongssuch as education, entertainment, tools, puzzle, music, etc. Itthen looks at apps of the same category and same subcategorythat it has knowledge about to decide if the set of permissionrequested by the app to be installed is reasonable. This processalso relies on the input from expert users. From the previousselections of experts users for that app, RecDroid makes asuggestion of whether or not to put the app into probationmode.Intercepting permission requests: Since intercepting permission requests requires OS level access, we create a smallsoftware patch to modify client’s operating system. We investigated different potential approaches to perform OS modification and designed a solution that causes minimum impact tolegacy apps and applicable to a broad range of OS versions,hardware platforms, and permission access models. One mightargue that collecting this permission granting behaviors fromusers could raise privacy concern. However, since the portaldoes not collect any actual sensitive information, the data itcollects doesn’t contain private information. In fact, the portalmerely communicates three-tuple data in the form of AppID,Permission Request, User’s responses .Bootstrapping the service: In order to suggest plausibleresponses to users, RecDroid starts from a set of seed expertusers and make recommendation based on their responses.However, it is practical to have our expert users to provideplausible responses to hundreds of thousands of apps available on the market. To address this scalability challenge, wepropose a spanning algorithm that searches for external expertusers based on the similarity of their responses to our set ofinternal experts, in combination with the user’s accumulativereputation. Our recommendation for an app is based on theaverage of top 𝑁 expert users in combination with the responsethat is selected by majority of participants. Having the sameIn this section, we investigate an algorithm to seek expertRecDroid users. Suppose we have a set of users 𝑈 and amongthem set 𝐸 𝑈 is a set of initial seed expert users. Forinstance, the security experts are employed by RecDroid tomonitor the permission requests from apps. The seed expertsrespond to the permission requests from selected apps basedon their professional judgment. Their responses are consideredaccurate and are used in the system as ground truth. However,due to limited budget and manpower, the number of apps thatcan be covered by seed experts is small, compared to the entireapp base that RecDroid monitors. In this paper, we use set 𝐴to denote all apps that are monitored by RecDroid.Suppose initially each of our seed expert users 𝐸 haveresponded to a set of apps of their choice. The apps respondedby an seed expert user 𝑒 𝐸 are denoted by 𝐴(𝑒). Since theremay be multiple permission requests popped up during an appusage, we use 𝑅(𝑎) to denote the set of requests the app 𝑎 𝐴may have. We use 𝑅𝑒 to denote all requests that are coveredby RecDroid seed expert users, named labeled requests. Thenwe have,𝑅𝑒 𝑒 𝐸 𝑎 𝐴(𝑒) 𝑅(𝑎)(1)How to determine whether a user is expert user or not? Inour approach we propose a ranking algorithm to evaluate theexpertise level of a user based on the ratio of correctness onhis/her responses to app requests. Let 𝑝𝑖 denote the probabilitythat user 𝑖 correctly responds to permission requests. Ourmission is to estimate 𝑝𝑖 based on the number of correctand incorrect responses that user 𝑖 has responded in thepast. Our approach is to observe all labeled requests thatare independently responded (without recommendation) bythe user, and compute the ranking of the user based on thenumber of correct/incorrect responses to those requests. Forthe convenience of presentation, we drop the subscript 𝑖 in therest of the notations.We use notation 𝛼 to represent the cumulative number ofrequests that are responded in consistent with seed expertsand 𝛽 requests are responded opposite to the experts’ advice(note that the labels from seed experts arrive later than theuser’s responses). Furthermore, we use a random variable 𝑋 {0, 1} to denote an random variable that a user answers the2015 IFIP/IEEE International Symposium on Integrated Network Management (IM2015)299

permission requests correctly or not. Where 𝑋 1 representsthat user responds to a request correctly, vice verso. Therefore,we have 𝑝 ℙ(𝑋 1). Given a sequence of observations on𝑋, a beta distribution can be used to model the distribution of𝑝.In Bayesian inference, posterior probabilities of Bernoullivariable given a sequence of observed outcomes of the randomevent can be represented by a beta distributions. The betafamily of probability density functions is a continuous familyof functions indexed by the two parameters 𝛼 and 𝛽, wherethey represent the accumulative observation of occurrenceof outcome 1 and outcome 0, respectively. The beta PDFdistribution can be written as:𝑓 (𝑝 𝛼, 𝛽) Γ(𝛼 𝛽) 𝛼 1𝑝(1 𝑝)𝛽 1Γ(𝛼)Γ(𝛽)(2)The above can also be written as,𝑝 Γ(𝛼 𝛽) 𝛼 1𝑦(1 𝑦)𝛽 1Γ(𝛼)Γ(𝛽)(3)In our scenario, the parameters 𝛼 and 𝛽 are the accumulatednumber of observations that the user respond to the permissionrequest correctly and incorrectly, respectively.Let 𝑥𝑛 {0, 1} be the 𝑛𝑡ℎ observation in the past, where𝑛 ℕ. The accumulative observations of both correct andincorrect responses from a user after 𝑛 observations can bewritten as,We use 𝑠 to represent the expertise ranking of the user.Then we can compute 𝑠 using the following formula,𝑠 𝑚𝑎𝑥(0, 𝔼[𝑌𝑖 ] 𝑡𝜃𝛿[𝑌𝑖 ]) 𝛼𝛼𝛽 𝑡𝜃) 𝑚𝑎𝑥(0,𝛼 𝛽(𝛼 𝛽)2 (𝛼 𝛽 1)(11)Where 𝑡 [0, ) represents a conservation factor wherea higher value means our ranking mechanism is more con2 𝑞servative to less confident estimation. 𝜃 1 𝑞 is thenormalization factor, which is to decouple the forgetting factorand expertise rating.We can see that the higher ratio a user responds to permission requests correctly, the higher ranking score it receivesthrough RecDroid system; the more samples the system knowsabout the user, the higher score it receives.Given the ranking scores of users, we can use a simplethreshold 𝜏 to identify expert users from novice users. Thatis, if a user 𝑖 has 𝑠𝑖 𝜏 , then it is labeled as an expert user.The ranking scores will be used to make recommendations toother app users when permission requests pop up.In the next subsection, we propose an algorithm to generaterecommendation on app permission requests based on existingresponses from other users who have used the same app.B. Response Aggregation through Weighted Voting𝛼𝑛 𝑛 𝑞 𝑛 𝑘 𝑥𝑘 𝑞 𝑛 𝐶0(4)𝑘 1 𝑥𝑛 𝑞𝑥𝑛 1 . 𝑞 𝑛 1 𝑥1 𝑞 𝑛 𝐶0𝑛 𝛽𝑛 𝑞 𝑛 𝑘 (1 𝑥𝑘 ) 𝑞 𝑛 𝐶0(5)𝑘 1 (1 𝑥𝑛 ) 𝑞(1 𝑥𝑛 1 ) . 𝑞 𝑛 1 (1 𝑥1 ) 𝑞 𝑛 𝐶0Where 𝐶0 is a constant number denoting the initial believeof observations; 𝑞 [0, 1] is the remembering parameter whichis used to discount the influence from past experience andtherefore emphasize the importance of more recent observations.Equation 4 and 5 can also be written into an iterative formas follows:𝛼0 𝛽0 𝐶0𝛼𝑛 𝑥𝑛 𝑞𝛼𝑛 1𝛽𝑛 (1 𝑥𝑛 ) 𝑞𝛽𝑛 1(6)(7)(8)Let random variable 𝑌 represent the possible value that thetrue expertise level of a user can be, then we have,𝛼(9)𝔼[𝑌 ] 𝛼 𝛽𝛼𝛽(10)𝛿 2 [𝑌 ] (𝛼 𝛽)2 (𝛼 𝛽 1)300When a user receives a permission request from an appin probation mode, RecDroid system attempts to make arecommendation to the user regarding whether he/she shouldgrant the request. If the app has been investigated by our seedexpert users, then the response from the seed experts will berecommended to the user. However, due to the limitation ofour seed experts, majority of apps may not be covered by seedexperts. In this case, we aggregate the responses from otherusers and recommend the aggregated response if confidencelevel is high enough.The proposed approach in this paper is called weightedvoting. The voting process is divided into three steps: qualification, voting, and decision. The algorithm is described inAlgorithm1.In the qualification step, only responses from qualifiedusers are included into the voting process. Initially the ballotcount for reception decision and rejection decision are equallyinitialized to 𝐷0 . For each qualified voter, the weight ofthe cast ballot is the ranking score of the voter. After thevoting process finishes, the average ballot score is used tomake a final decision. If the average ballot score exceeds adecision threshold, then corresponding recommendations aremade. Otherwise, no recommendation is made.V.E VALUATIONTo evaluate the performance of RecDroid, we conducteda set of simulation experiments to measure the accuracy,reliability, and effectiveness of the system.2015 IFIP/IEEE International Symposium on Integrated Network Management (IM2015)

Algorithm 1 Weighted Voting for Recommendation DecisionThis algorithm is to decide whether to make recommendation,and what recommendation to make given the response from otherregular users.Notations :𝑀 :the set of users who have responded to the permission question𝑠𝑖 :the ranking of the 𝑖𝑡ℎ user𝑥𝑖 :the response of the 𝑖𝑡ℎ user𝜏𝑒 :the minimum required ranking score to be classified into expertusers𝜏𝑑 :the recommendation threshold𝑎, 𝑏 :the cumulative ballots for reception and rejection decision𝐷0 :the initial ballot count for both decisions//initialize voting parameters𝑎 𝑏 𝐷0for each user 𝑢 in 𝑀 doif 𝑠𝑢 𝜏𝑒 then//only qualified users responses are considered into the votingif 𝑥𝑢 1 then𝑎 𝑠𝑢else𝑏 𝑠𝑢end ifend ifend for//decision making based on final ballots result𝑎if 𝑎 𝑏 1 𝜏𝑑 thenRecommend to accept the request𝑎else if 𝑎 𝑏 𝜏𝑑 thenRecommend to reject the requestelseNo recommendationend ifA. Simulation SetupAs a proof of concept we set up a RecDroid users profileto be a set of 100 users consisting of three different levelsof expertise. Note that the expertise we refer here is theprobability that a user answers permission requests correctly(a.k.a. consistent with standard answers). Among the 100users, 40% are with a high level of expertise (0.9), 30% arewith a medium level of expertise (0.5), and the remaining 30%are with a low level of expertise (0.1) . Unless particularlyspecified in the experiments, we fix the number of requestsanswered by users to 100.Our simulation environment is MATLAB 2013 on a Windows machine with 2.5Ghz Intel Core2 Duo and 4G RAM. Allexperimental results are based on an avera

Dude, Ask The Experts!: Android Resource Access Permission Recommendation with RecDroid Bahman Rashidi Carol Fung Department of Computer Science Virginia Commonwealth University Richmond, VA, USA {rashidib, cfung} Tam Vu Department of Computer Science and Engineering University of Colorado Denver Denver, CO, USA [email protected]