The permission system is not a list of tick boxes: it is an architecture of isolation, and understanding it explains both why phones are safer than computers and where the weak points remain.
It expands on the recommendation checking what your apps can do.
The principle: every app in a closed room
On mobile systems every application runs in a space isolated from the others. It has its own storage area, and it cannot read the other apps’ data.
It is a substantial difference from traditional computers, where a program can typically reach all the user’s files.
Two consequences follow from that isolation:
Everything outside the room requires a permission. Camera, microphone, contacts, location, shared files: they are the system’s resources, not the app’s.
The system is the only intermediary. The app does not reach the hardware directly: it asks the system, which checks the permission and answers. That is where your settings take effect.
The levels of permission
They do not all work the same way.
| Level | How it gets granted | Examples |
|---|---|---|
| Automatic | Declared by the app, granted without asking | Internet access, vibration |
| On request | A dialogue box at the moment of use | Camera, microphone, contacts, location |
| Special | It goes through the settings, with explicit warnings | Accessibility, overlay, administration |
| System | Reserved for the manufacturer | Internal functions |
The third row is deliberately designed to be inconvenient: the system does not offer a window with “allow”, it sends the user to a settings screen, with a warning explaining what it means.
That inconvenience is a security measure, and it is why techniques aiming to obtain accessibility have to convince the user through several steps.
The evolution: from “everything at the start” to “only when needed”
It is worth telling, because it explains why old devices are in a worse position.
Before: permissions were granted all together at installation. Either you accepted the complete list, or you did not install. No partial choice, no revocation.
Then: the request became contextual — at the moment the app uses the function — and revocable at any time.
Today: the middle grounds have been added.
| Development | What it allows |
|---|---|
| Only while using the app | Access limited to the foreground |
| Only this time | Access valid for one session |
| Selected items | Only the photos or contacts you choose |
| Reduced precision | An area instead of a point |
| Automatic revocation | Permissions lapse if the app goes unused |
| A usage indicator | A visible signal when the resource is in use |
The last two are the most interesting because they require no decision from the user: they do maintenance and inform on their own.
What happens when you revoke a permission
A practical question, with a reassuring answer.
The app is not warned in advance. It discovers the revocation when it tries to use the resource and gets refused.
The app does not break. It is designed to handle a refusal: it will show a message, or disable a feature. The stores explicitly require an app to stay usable when a non-essential permission is denied.
The effect is immediate. No restart and no uninstalling needed.
It is reversible. Granting again takes two taps.
The data already obtained stays where it was. Revocation closes future access, it does not recover the past: it is why the initial decision counts more than the correction.
That is why reviewing permissions carries no risk: at worst a feature stops working, you find out at once, and you grant it again.
The checks before publication
A piece of the picture explaining why installing from the official store matters.
Before being published, an app goes through some checks:
Automatic checks. Code analysis looking for behaviours known to be harmful, verification of the included libraries, comparison against archives of problematic software.
Checks on the consistency of the permissions. Some permissions require explicit justification from the developer, and can be refused if the declared function does not justify them.
Manual sample checks, more frequent for apps requesting sensitive permissions.
Developer identification, answering with a verified identity.
Monitoring after publication, with the ability to remove an app and, in some cases, uninstall it from devices.
What these checks manage to do: catch openly harmful software, before and after publication. It is the main reason why installing from the official store greatly reduces the risk.
What they cannot do: judge whether a declared and permitted collection is proportionate. That judgement cannot be delegated, because it depends on what a person is willing to exchange — and it is exactly the space this recommendation occupies.
What the system CANNOT control
It is the most important part of this unit, because it marks the boundary of what the architecture protects.
What the app does with the data it legitimately obtained. If you grant access to contacts, the system does not know and does not control whether those contacts get sent to a server. The permission governs access, not later use.
That is why the remedy sits upstream: deciding whether to grant, because afterwards the system no longer intervenes.
What the app transmits. Network permission is automatic and universal. No app has to ask permission to communicate.
The content of the privacy notices. The stores require declarations about the data collected, and the checks exist, but they are self-declarations: the system does not verify them one by one.
A change of ownership. An app can be sold to somebody else, and whoever acquires it inherits the permissions already granted by millions of users. It is a documented case, and it mainly concerns browser extensions.
Why browser extensions are different
They deserve a paragraph because they escape this architecture.
An extension does not run in an isolated room: it runs inside the browser, and the browser is the app seeing everything you do online.
An extension’s typical permission — “read and change your data on the sites you visit” — is far broader than any mobile app’s permission. It includes the sites where you type credentials.
Browsers have introduced limitations — per-site permissions, activation on request — but they remain the point where the most gets granted with the least awareness.
The case of separate profiles
A useful and little-used function: many systems allow a work profile separate from the personal one on the same device.
The two areas are isolated: one’s apps do not see the other’s data, the permissions are separate, and the contacts stay distinct.
It is the structural solution to the problem of a personal device used for work — better than any care over individual permissions, because it does not depend on remembering.
Third-party libraries: the invisible piece
A little-known technical aspect explaining why even honest apps collect more than it seems.
No app is written entirely from scratch. Every developer includes third-party libraries for common functions: advertising, usage statistics, error reporting, maps, payments, signing in with existing accounts.
Every included library runs inside the app and with its permissions.
| Kind of library | What it can see |
|---|---|
| Advertising | Identifiers, location if granted, interests |
| Usage statistics | How you use the app, when, for how long |
| Error reporting | Information about the device and its state |
| Maps | Your location, if granted |
| Sign-in with an account | The identity you sign in with |
The relevant point: a single app can include a dozen of them, and each transmits to a different party. The developer often does not have complete visibility over what each one does.
That explains two things:
Why the data declaration is often broad. It is not necessarily bad faith: it is the sum of what the included components collect.
Why a free app collects more than a paid one. The first includes advertising libraries; the second often does not.
And it suggests a practical choice: when a paid version exists of an app you use a lot, often you are not buying features — you are buying the absence of those libraries.
How permissions are made visible
A recent development worth knowing, because it changed what can be checked.
The real-time indicator. A dot or icon appears when the microphone or camera is in use. It is visible over any app and it cannot be hidden: even an app wanting to mask it could not, because it is drawn by the system.
The historical report. A screen listing which apps used which permissions, when and how many times, over the last hours or days.
The summary notifications. A periodic alert flagging the use of sensitive permissions by apps in the background.
The store labels. The compulsory declaration of which data an app collects and who it shares it with, visible before installing.
The provenance indication. Some systems flag when content or an app comes from a source other than the official store.
Together, these functions have moved the problem: until a few years ago there was no way to know what an app was doing; today there is, and it is two taps away.
What is missing is no longer the information. It is the moment when somebody looks at it — and no operating system can create that for the user.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Skills | Understanding the permission levels and what changes between them |
| Awareness | Knowing that the system governs access, not later use |
| Secure Behaviour | Deciding upstream, because afterwards the system does not intervene |
Reference level: FL3 — Autonomous.
Summary
- Every app is isolated: everything outside requires a permission.
- The special permissions are made deliberately inconvenient: it is a security measure.
- The system controls access, not the use of data already obtained.
- Browser extensions hold far broader permissions than mobile apps.
One thing to do today. Revoke a permission from an app you think does not need it, and open the app. In almost every case nothing will happen — and it is the best way to convince yourself the review is painless.
Related content
- Checking what your apps can do — the recommendation this expands on
- How to review granted permissions — where to act, in practice
- Impact of excessive permissions — what each level allows
- Permission abuse — what exploits the limits of this architecture
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
