Unused permissions after first install should prompt a keep-or-drop review
Aliases: unused permission · permission auto-reset · idle grant
What it is
A permission granted shortly after install, then never actually read for weeks, should become visible as "this grant is still on, and it has not been used," with a choice to keep or turn off. That is making idle state visible—not a calendar review of every ongoing lease, and not the job of a system occupancy dot. The idle prompt targets grants that never paid out, so a capability collected at launch does not sediment into a permanent background right.
Why it happens
An Allow in the first session is often a way to dismiss a dialog, or a bet that "I might need this later." If later never comes, grant and use have split: risk remains, benefit is zero. Idle is invisible: Settings lists are not sorted by last genuine read, and the app rarely volunteers weakness. Labeling "granted but never used" supplies the missing evidence of use, so keeping it is an informed choice. OS auto-reset of unused permissions is the platform version of the same mechanism. An in-app prompt is notice before that reset, not another system dialog.
Where it stops holding
A permission read every day is not idle; do not use this prompt to nag. If the system is already showing "unused permissions will be reset," do not stack a full screen with the same content; mark the settings row "the system is about to reclaim this." Enterprise-mandated capabilities cannot be offered as turn-off. A permission still not-determined is not idle; prompting would become an extra ask at the wrong time.
Applying it
- Record first genuine read time for every granted permission. If the count is still zero after the install interval, list those permissions at the top of Settings or in one dismissible in-app notice.
- Each row offers keep and "go turn off." Turn off jumps to Settings; do not call the authorization API from the prompt.
- Cap how often the prompt appears; after dismiss, stay silent for the same interval.
- Verify in a test build by holding a granted permission at zero reads and advancing the interval: one idle list should appear, and its items should match the zero-read set. Turn off must land on the correct toggle. The main path must not fire a system permission dialog for this. If the OS has already auto-reset, the in-app row must show Deny or not-determined on next foreground, not leftover Allow.
Related
- Within the group: H4.10.1 System in-use indicators and in-app permission entries do different visibility jobs · H4.10.2 When Settings revokes a permission, the app must detect it and degrade · H4.10.3 A mismatch between shown permission state and actual availability is misdiagnosed as a bug
- Adjacent: H4.07 One-time vs Ongoing Authorization · H4.04 Revocable Permissions · O1.10 Consent Granularity and Withdrawal
- Search terms:
unused permission·permission auto-reset·stale grant