Application permissions are granted once, in a second, and then apply indefinitely to software that updates itself. The structural gap between a one-time decision and continuous execution, and the small number of practices that actually narrow it.
A grant is not a transaction
The prompt appears, two buttons, and tapping one makes it go away. It has the shape of a completed action — like paying for something, where the exchange happens and is over.
It is not that. It is the start of an arrangement that runs continuously until revoked, and revoking is a thing almost nobody does, because nothing ever prompts them to.
Three gaps between the grant and the use
Time. The permission applies indefinitely. What you granted for one task on one afternoon two years ago still applies this morning, and nothing has asked you since.
Scope. Grants are per category, not per purpose. Location for the map is the same grant as location for anything else the software decides to do with location, and the interface has no vocabulary for the difference.
Identity. The software updates. What you evaluated is not what is running now, and the permission carries across without being re-asked. That continuity is deliberate — nobody wants to re-approve everything weekly — and it is also precisely the gap.
Why interfaces cannot show you this
A settings page shows state: a list of who currently holds what. That is genuinely all it is built to show.
It cannot show frequency, purpose, or what was done with the result. The one thing that would actually inform a decision — this permission was used four hundred times last month, mostly while the application was closed — is the thing almost no interface presents, and its absence is what sustains the impression that a grant is inert until used in front of you.
What the good implementations changed
Real improvements, each narrowing one of the three gaps.
Prompting at the moment of use rather than at installation narrows scope: you are asked while the purpose is visible, so the decision has context attached.
One-time and while-in-use grants narrow time, by ending the arrangement instead of letting it persist by default.
Grants that lapse when software is unused narrow time as well, and address dormancy, which is where the risk concentrates.
Indicators showing a sensor is live narrow identity, by making execution visible rather than inferred — you can at least see that something is happening now.
Where it still leaks
Permissions granted on behalf of other software. Integrations and sign-in relationships extend access to parties you never evaluated, through a single tap that did not mention them.
Background access, which is the same permission with no moment at which you would notice it being exercised.
Permissions that are functionally mandatory because the feature is the product. Refusing is available and means not using the thing, which makes the choice formal rather than real.
What a person can actually do
Review grants periodically, not at install. The install-time decision is the one made under pressure, while you are trying to do something else; a review on a quiet Sunday is a different decision made by a different version of you.
Remove software you no longer use, which removes its grants with it, and is the highest ratio of effect to effort available here.
Prefer one-time or while-in-use wherever offered.
Treat any grant held by dormant software as one to revoke. Dormant is where this concentrates: still permitted, still updating, no longer watched by anybody.
The same shape elsewhere
Browser extensions. Connected home devices. Any integration authorised once during setup and never seen again. Every one of them is a single decision governing continuous behaviour, with no mechanism that re-opens the question.
Once you can see the shape, you find it in most places software asks you for something.
Close
The grant was not the end of a decision. It was the beginning of an arrangement, and it has been running ever since, on your behalf, without asking again.