pith. sign in

arxiv: 1906.10873 · v2 · pith:JMUWAKSMnew · submitted 2019-06-26 · 💻 cs.CR

Making Smartphone Application Permissions Meaningful for the Average User

Pith reviewed 2026-05-25 16:07 UTC · model grok-4.3

classification 💻 cs.CR
keywords smartphone permissionsuser-tangible servicesmiddlewarepermission systemAndroid securityprivacy expectationsapplication controluser understanding
0
0 comments X

The pith

Smartphone permissions can shift from device resources to user-tangible services via middleware without refactoring applications.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper identifies a mismatch between the current Android-style permission model, which describes access to technical resources, and what average users understand about privacy risks. It proposes redefining permissions around user-tangible services such as contacts, location, or messages. A middleware layer can present this new view on top of existing permission systems. If successful, this would let users make more informed decisions about app installations without requiring changes to how apps are written. The approach targets the gap that allows questionable apps to access private information on smartphones.

Core claim

The paper claims that the UNIX-rooted permission system is both too coarse and too fine-grained because it uses the wrong axes, and that replacing the paradigm of an app accessing device resources with one where an app accesses user-tangible services, implemented through a simple middleware wrapper around today's permission system, closes the conceptual gap for users without any refactoring of applications.

What carries the argument

Middleware that wraps a view of application control based on user-tangible services around the existing permission system.

If this is right

  • Existing applications continue to function unchanged while users see a different permission model.
  • The security model remains compatible with current platforms such as Android.
  • Users encounter permissions expressed in terms of everyday services rather than low-level resources.
  • The middleware approach avoids the need for a full redesign of the underlying operating system permission mechanisms.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar middleware wrappers could be explored for other permission-based systems outside smartphones.
  • Standard categories of user-tangible services might emerge as a practical next step.
  • The approach leaves open whether the service framing itself needs further refinement through user testing.

Load-bearing premise

That framing permissions as access to user-tangible services will lead users to make meaningfully different and better decisions than the current resource-based model.

What would settle it

A controlled study in which users are shown identical apps under both permission framings and their installation or permission-granting choices are compared for differences in rate or pattern.

Figures

Figures reproduced from arXiv: 1906.10873 by Amer Chamseddine, George Candea.

Figure 1
Figure 1. Figure 1: Installing Android apps: On the left, a weather forecast app requests full access to the Internet (unnecessar￾ily coarse grained). On the right, a VoIP app requests access to “send sticky broadcast,” “reroute outgoing calls,” etc. (too technical for an average user). UNIX-style users and groups, respectively. When installing a new app, Android creates a new userid for it, and runs the app as that user. And… view at source ↗
Figure 2
Figure 2. Figure 2: Our proposed Split/Merge Permissions Proxy archi￾tecture. Here, A1 follows the traditional style of Android per￾missions, and requests its permissions directly from the OS, whereas A2 requests the semantically meaningful permissions to collect usage statistics and communicate with its server. Compared to today’s permission system, our pro￾posed system requires strictly less trust from the end user, because… view at source ↗
read the original abstract

Smartphones hold important private information, yet users routinely expose this information to questionable applications written by developers they know nothing about. Users may be tempted to think of smartphones as old-style dumb phones, not as powerful network-connected computers, and this opens a gap between the permissions-based security paradigm (offered by platforms like Android) and what users expect. This makes it easy to fool users into installing applications that steal their information. Not surprisingly, Android is now a more favored target for hackers than Windows. We propose an approach for closing this gap, based on the observation that the current permissions system--rooted in good ol' UNIX-style thinking--is both too coarse and too fine grained, because it uses the wrong axes for defining the permissions space. We argue for replacing the paradigm in which "an app accesses device resources" (which is foreign to most non-geeks) with a paradigm in which "an app accesses user-tangible services." By using a simple piece of middleware, we can wrap this view of application control around today's permission system, and, by doing so, no conceptual refactoring of applications is required.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims that the Android permission system is mismatched to user expectations because it is rooted in resource-access thinking that is both too coarse and too fine-grained; it proposes replacing this with a paradigm of 'user-tangible services' and asserts that a simple middleware layer can wrap the existing permission system to present this view without requiring any conceptual refactoring of applications.

Significance. If the middleware construction can be shown to work and to improve user comprehension, the idea would address a well-known usability gap in mobile security that contributes to over-granting of permissions and successful malware. The proposal is forward-looking and identifies a genuine conceptual mismatch, but its significance remains prospective until the translation mechanism is specified and evaluated.

major comments (2)
  1. [Abstract] Abstract: the central assertion that 'a simple piece of middleware' can wrap the existing permission system to re-express accesses as user-tangible services while preserving app behavior and OS enforcement is stated without any mechanism, mapping rules, interception strategy, or runtime translation example (e.g., how 'access fine location' becomes 'share my location with contacts'). This premise is load-bearing for the claim that no conceptual refactoring of applications is required.
  2. [Abstract] Abstract: the paper offers no user study, illustrative mapping, or even a single worked example showing that re-expressing permissions in terms of user-tangible services would actually close the gap between the technical model and average-user expectations; the argument therefore rests entirely on an untested conceptual premise.

Simulated Author's Rebuttal

2 responses · 0 unresolved

Thank you for the opportunity to respond to the referee's report. The comments correctly identify that the manuscript presents its core idea at a conceptual level. We address each major comment below.

read point-by-point responses
  1. Referee: [Abstract] Abstract: the central assertion that 'a simple piece of middleware' can wrap the existing permission system to re-express accesses as user-tangible services while preserving app behavior and OS enforcement is stated without any mechanism, mapping rules, interception strategy, or runtime translation example (e.g., how 'access fine location' becomes 'share my location with contacts'). This premise is load-bearing for the claim that no conceptual refactoring of applications is required.

    Authors: The referee is correct that the abstract states the middleware premise at a high level without specifying mechanisms or examples. The manuscript is a conceptual proposal focused on reframing the permission paradigm rather than a systems paper detailing implementation. We will revise the manuscript to include a high-level description of a possible interception approach (e.g., via Android's permission broker or proxy layers) and at least one concrete mapping example to illustrate feasibility while preserving app behavior and OS enforcement. revision: yes

  2. Referee: [Abstract] Abstract: the paper offers no user study, illustrative mapping, or even a single worked example showing that re-expressing permissions in terms of user-tangible services would actually close the gap between the technical model and average-user expectations; the argument therefore rests entirely on an untested conceptual premise.

    Authors: We agree that the manuscript contains no user study, mappings, or worked examples. As a conceptual contribution identifying a paradigm mismatch, the paper does not claim empirical validation. We will add an illustrative worked example in the revision to make the translation concrete. A full user study lies beyond the scope of this work and would be appropriate for follow-on research. revision: partial

Circularity Check

0 steps flagged

No circularity; proposal is a forward-looking conceptual argument without self-referential derivation or fitted inputs

full rationale

The paper presents a high-level proposal to reframe Android permissions around 'user-tangible services' via middleware, without any equations, parameter fitting, or mathematical derivation. No load-bearing step reduces to a prior self-citation, self-definition, or renamed known result; the text simply states the observation that current permissions are 'too coarse and too fine grained' and asserts that middleware can wrap the existing system. This is a design suggestion rather than a closed derivation chain, so the argument remains self-contained against external benchmarks and does not exhibit any of the enumerated circularity patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The proposal rests on the domain assumption that users find resource-based permissions confusing and that a service-based view will be clearer; no free parameters or invented physical entities are introduced.

axioms (2)
  • domain assumption The current permissions system is both too coarse and too fine grained because it uses the wrong axes.
    Stated directly in the abstract as the motivation for the new paradigm.
  • domain assumption Users routinely expose private information because they do not understand the permission model.
    Opening premise of the abstract.
invented entities (1)
  • Middleware layer that translates resource permissions into user-tangible services no independent evidence
    purpose: To wrap the existing permission system without requiring app changes
    Introduced as the mechanism that enables the new view; no independent evidence of correctness or usability is provided.

pith-pipeline@v0.9.0 · 5724 in / 1352 out tokens · 36346 ms · 2026-05-25T16:07:27.178040+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

16 extracted references · 16 canonical work pages

  1. [1]

    Aimonetti

    J. Aimonetti. Nielsen: 1 in 2 own a smartphone, average 41 apps. CNET Technology Reviews,M a y

  2. [2]

    http://reviews.cnet.com/8301-19512_7-57435397- 233/nielsen-1-in-2-own-a-smartphone-average-41-apps/

  3. [3]

    http://developer.android.com/guide/ topics/security/permissions.html

    Android permissions. http://developer.android.com/guide/ topics/security/permissions.html

  4. [4]

    http://developer.android

    Android permissions reference. http://developer.android. com/reference/android/Manifest.permission.html

  5. [5]

    Pausing Google Play: More than 100,000 Android apps may pose security risks

    Bit9. Pausing Google Play: More than 100,000 Android apps may pose security risks. https://www.bit9.com/files/ 1/Pausing-Google-Play-October2012.pdf, Oct. 2012

  6. [6]

    T. Bradley. Study finds 25 percent of android apps to be a security risk. PCW orld,N o v .2 0 1 2 . http://www.pcworld.com/article/2013524/study-finds- 25-percent-of-android-apps-to-be-a-security-risk.html

  7. [7]

    Burrows, M

    M. Burrows, M. Abadi, and R. Needham. A logic of au- thentication.ACM Transactions on Computer Systems, 8(1):18–36, Feb 1990

  8. [8]

    Cadar, D

    C. Cadar, D. Dunbar, and D. R. Engler. KLEE: Unas- sisted and automatic generation of high-coverage tests for complex systems programs. InOSDI,2 0 0 8

  9. [9]

    Chipounov, V

    V . Chipounov, V . Georgescu, C. Zamfir, and G. Candea. Selective symbolic execution. InHotDep,2 0 0 9

  10. [10]

    A. P . Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagner. Android permissions: User attention, com- prehension, and behavior. InSOUPS,2 0 1 2

  11. [11]

    K. J. Higgins. http://www.darkreading.com/mobile- security/167901113/security/privacy/240012705/more- than-25-of-android-apps-know-too-much-about- you.html, Nov. 2012

  12. [12]

    B. Levine. Be wary of free Android apps. http://www.sci- tech-today.com/story.xhtml?story_id=13200006Q1XO

  13. [13]

    I. Lunden. In mobile apps, free ain’t free, but cambridge university has a plan to fix it. TechCrunch,M a r .2 0 1 2 . http://techcrunch.com/2012/03/06/in-mobile-apps-free- aint-free-but-cambridge-university-has-a-plan-to-fix-it/

  14. [14]

    A. Mindlin. Using phones, but not to talk or surf. The New York Times ,M a r . 2 0 1 1 . http://www.nytimes.com/2011/03/07/business/me- dia/07drill.html

  15. [15]

    Reisinger

    D. Reisinger. Android overtakes Windows as top threat. MIT Technology Review, Dec. 2012. http://www.technologyreview.com/view/508316/the- changing-face-of-security-android-overtakes-windows- as-top-threat/

  16. [16]

    R. Ritchie. iOS 6 wants: Granular privacy control.iMore, Feb. 2012. http://www.imore.com/path-apps-accessing- contacts-inspiration-android. 6