Source-linked AI summary
Android Permissions Remystified: A Field Study on Contextual Integrity
Primal Wijesekera, Arjun Baokar, Ashkan Hosseini, Serge Egelman, David Wagner, Konstantin Beznosov
TL;DR
Smartphone permission systems must balance decision fatigue against users’ concerns about unexpected data access. The paper instruments Android and studies permission use with 36 participants in the field, finding that many requests were viewed as invasive and that users wanted greater control.
Problem
Permission systems risk habituation when users face frequent benign decisions, yet users may object when applications access sensitive data without matching their expectations.
Method
The authors instrumented Android, collected protected-resource access and contextual data, and surveyed 36 participants about sampled requests.
Results
80% of participants deemed at least one permission request inappropriate, and participants wanted to block access to protected resources a third of the time.
Takeaways & Limitations
Permission systems should tailor runtime notifications to individual users and account for whether application access is obvious in context.
Takeaways & Limitations
Accurately modeling user preferences may require learning each user’s judgments over time because individual characteristics explain substantial response variance.
Abstract
from arXiv · showhide
Due to the amount of data that smartphone applications can potentially access, platforms enforce permission systems that allow users to regulate how applications access protected resources. If users are asked to make security decisions too frequently and in benign situations, they may become habituated and approve all future requests without regard for the consequences. If they are asked to make too few security decisions, they may become concerned that the platform is revealing too much sensitive information. To explore this tradeoff, we instrumented the Android platform to collect data regarding how often and under what circumstances smartphone applications are accessing protected resources regulated by permissions. We performed a 36-person field study to explore the notion of "contextual integrity," that is, how often are applications accessing protected resources when users are not expecting it? Based on our collection of 27 million data points and exit interviews with participants, we examine the situations in which users would like the ability to deny applications access to protected resources. We found out that at least 80% of our participants would have preferred to prevent at least one permission request, and overall, they thought that over a third of requests were invasive and desired a mechanism to block them.
1 Introduction
Android’s permission model can burden users with poorly understood decisions and habituation, while prompting too rarely may expose data in ways that violate expectations. This study examines real-world protected-resource access and users’ desire to block requests.
- Few people read Android permission requests, and even fewer comprehend them.
- Android applications present users with an average of four permission requests during installation, creating a risk of habituation.
- Contextual integrity treats privacy violations as uses of personal information that defy users’ expectations.
- 36 participants used instrumented Android phones as their primary phones for one week, followed by exit surveys about protected-resource access.
- Participants wanted to block access to protected resources a third of the time, based on privacy concerns and understanding of application needs.
- The study contributes a field quantification of permission use and models when runtime classifiers might prompt users about permission decisions.
2 Related Work
Prior work identifies weaknesses in Android’s permission ecosystem, including poor user comprehension, excessive application privileges, and surprising background data collection. Contextual integrity provides a framework for judging whether permission-related information flows match users’ expectations.
- Most users do not attend to Android permission requests, and fewer fully comprehend them; developers also lack complete permission knowledge.
- Applications often violate least privilege, while researchers have studied permission overuse, malicious applications, and static permission analysis.
- Users are often surprised when background applications collect data, and their concern can range from annoyance to seeking retribution.
- Dynamic blocking and data substitution systems can reduce privacy exposure but may break application functionality for one-third of tested applications.
- Reducing security decisions may decrease habituation, motivating decision mechanisms that automatically grant benign access while requiring approval for dangerous resources.
- Contextual integrity evaluates whether information flows are appropriate, but permission need can be ambiguous across applications such as location-sharing tools and games.
3 Methodology
The study instrumented Android to log protected-resource access and contextual information, then sampled access events for participant review. A 36-person field deployment and exit survey connected observed requests with users’ expectations and blocking preferences.
- The study collected actual protected-resource usage data and surveyed participants about whether requests were expected and should have been blocked.
- Android 4.1.1 was modified with a logging framework that recorded every access to permission-protected resources.
- Data Collection Architecture: Producers hooked Android API access points, while a Consumer logged events and uploaded them to the collection server.
- Data Collection: The instrumentation logged permission checks, ContentProvider access, and protected Intent access, along with the calling application and API method.
- Data Collection Architecture: The Consumer rate-limited logging after an application-permission pair exceeded 10,000 checks and averaged more than one check every 2 seconds.
- Contextual Data: Contextual data included application visibility, screen status, and connectivity, alongside timestamps.
- Experience Sampling: The study focused on 12 permissions recommended for runtime dialogs and randomly sampled screenshots when applications requested them.
- Recruitment: Recruitment screened adult T-Mobile users, and 36 participants ultimately used the experimental phones for the field study.
4 Application Behaviors
The study logged 27 million permission requests and found that most occurred without clear user awareness, while only a subset exposed sensitive data. Request frequency, visibility, and resource semantics complicate the design of runtime permission prompts.
- 27 million requests were logged from applications accessing Android-protected resources during participants’ phone use.The study examined access circumstances, especially when participants were not actively using the requesting applications.
- Visibility of permission requests: 60.00% of requests occurred while the screen was off, and fewer than one quarter occurred when users had clear indications that applications were running.Visible foreground requests accounted for 12.04%, while visible background services accounted for 12.86%, totaling 24.9%.
- Visibility of permission requests: Location access was usually invisible: fewer than 1% of location requests occurred while applications were visible or displaying a GPS notification.Applications often inferred location through cellular information or nearby WiFi SSIDs instead of directly querying GPS.
- Invisible permission requests: Invisible applications frequently accessed protected resources, including SMS messages at 125 times per user/day, browser history at 5 times per user/day, and the camera once per user/day.Users lacked contextual cues to understand that these requests were occurring, although access did not necessarily constitute a privacy violation.
- Request frequency: Some requests were frequent enough to require log rate limiting, while network checks primarily reported connection state and could adversely affect performance and battery life.The proposed NetworkCallback method might satisfy this need with fewer permission checks.
- What permission checks expose: Only 44.3% of the 11,598 analyzed permission checks exposed sensitive data, showing that permission checks and sensitive-data access were not equivalent.Location checks often retrieved provider or WiFi state information without exposing a participant’s location.
- Implications for runtime requests: The findings argue against both install-time all-or-nothing approval and prompting on every access, motivating a method that predicts when a request is likely appropriate to the user.A first-time approval may be appropriate in one context but surprising when the application continues accessing the resource in others.
5 User Expectations and Reactions
Participants evaluated 673 permission requests and wanted to block many requests, especially when access seemed unrelated, sensitive, or unexpected. Blocking was more common for invisible requests, while functional relevance and lower sensitivity supported allowing access.
- Study design: 673 permission requests were reviewed, averaging approximately 19 per participant.The sample included reactions to 423 requests occurring while participants actively used their phones.
- Reasons for blocking: 35% of 423 permission requests were requests participants would have preferred to block.Thirty participants, or 80% of the sample, wanted to block at least one request.
- Relevance to application functionality: 53% of 149 blocked requests were perceived as irrelevant to application functionality.Nineteen participants cited lack of necessity as a reason for blocking.
- Relevance to application functionality: 71% of 274 allowable requests were perceived as necessary for core application functionality.Thirty-one participants cited functional necessity when allowing at least one request.
- Expectations: Allowable requests averaged 3.2 for expectedness, compared with 2.3 for blocked requests.Lower expectation ratings indicate that blocked requests were less expected.
- Privacy concerns: 32% of 149 blocked requests involved data participants considered sensitive, while 21% of 274 allowable requests were allowed because the data seemed nonsensitive.Privacy concerns were cited by 53% of participants, whereas 66% cited low sensitivity when allowing requests.
- Visibility: 43% of 180 invisible requests were blocked, compared with 29% of 243 foreground requests.A Wilcoxon Signed-Rank test found a statistically significant difference (V=58, p<0.001).
- Screen state: Participants blocked 49.6% of 250 requests when the screen was off, compared with 35.2% of 423 requests when using their phones.Requests were also less expected when devices were not in use (µ = 2.66 versus µ = 3.26).
6 Modeling Users’ Decisions
The study modeled blocking decisions using runtime-available context and evaluated classifiers separately by screen state. Application visibility and identity were useful predictors, producing fair-to-good discrimination and substantial predicted blocking in logs.
- Modeling approach: Mixed-effects binary logistic regression modeled blocking from permission type, requesting application, and application visibility.The models accounted for both inter-subject and intra-subject correlations.
- Model selection: Separate screen-on and screen-off models fit better than one model including screen state as a fixed effect.For screen-on requests, the best-fitting model included application visibility and application name while controlling for subject effects.
- Evaluation: The classifiers used five-fold cross-validation and were applied to 1.3M logged sensitive requests.Four survey-data groups trained each model and one group evaluated it, repeated across five iterations.
- Classifier performance: AUC was 0.7 with screens on and 0.8 with screens off, compared with a random-classifier baseline of 0.5.The authors characterize these as a fair classifier and a good classifier, respectively.
- Log predictions: The screen-on model predicted blocking 35.29% of sensitive requests, averaging 645 blocked requests daily.With screens off, it predicted blocking 35.1% of requests, or 1,143 requests per user per day.
7 Discussion
The discussion interprets permission decisions through contextual integrity: users often rejected access that violated expectations, and their judgments varied by person, application, and contextual visibility. The authors therefore motivate selective, individualized runtime prompting while noting important scope boundaries.
- Findings: 80% of participants deemed at least one permission request inappropriate during one week of ordinary smartphone use.The authors characterize these accesses as violating contextual integrity because they defied users’ expectations.
- Implications: Runtime prompts could provide contextual information about what users were doing when protected resources were requested.The authors argue that prompts should be tailored to individual needs and whether application access is obvious.
- Implications: Prompting every request is infeasible because frequent prompts could overwhelm users and lead to habituation.The proposed challenge is to infer when a request is likely to be unexpected and prompt selectively.
- Personalization: Individual characteristics greatly explained variance in what different users considered appropriate, while privacy-scale responses did not explain those differences.The authors suggest learning each user’s preferences over time through a feedback loop.
- Contextual factors: Application identity and contextual cues about whether an application was running also influenced blocking decisions.The authors suggest prompting when an application the user is not actively using requests protected-resource access.
- Scope and limitations: The analysis was based on participants’ beliefs about which resources applications needed to function, and those beliefs may have been incorrect.The authors note that explanations of resource use could make users more permissive.
- Conclusion: The study demonstrates circumstances of Android permission requests under real-world usage and identifies ways to improve contextual integrity.The stated aim is to help system designers empower users to make better security decisions.
A Invisible requests
The appendix lists applications and permission types most frequently associated with invisible execution. Network state, wake locks, location, account access, and Wi-Fi state recur among these requests.
- Applications: Facebook App, Google Location, Facebook Messenger, Taptu DJ, and Google Maps appear among applications requesting permissions while running invisibly.The list associates each application with its most requested permission types.
- Permission types: ACCESS NETWORK STATE, WAKE LOCK, ACCESS FINE LOCATION, GET ACCOUNTS, and ACCESS WIFI STATE are listed as frequently requested invisible-execution permissions.The appendix also lists applications associated with each permission type.
B Permission Type Breakdown
The table identifies the permissions used most frequently during the study period.
- The table lists the most frequently used permissions during the study period.
- Its entries concern permission use during the study period.
- The table focuses on frequency of permission use.
C User Application Breakdown
The table identifies which applications most frequently requested access to protected resources during the study period.
- The table shows the applications that most frequently requested access to protected resources during the study period.
- The entries concern application requests for access to protected resources.
- The table ranks applications by request frequency during the study period.
D Distribution of Requests
The section presents two graphs describing request distributions: one averages requests across a given day, while the other shows request counts across days for each user.
- The first graph shows the distribution of requests throughout a given day averaged across the dataset.
- The second graph shows the distribution of request counts across days for each user.
- The graphs use number of requests as their measured quantity.