A permission is not information you hand over: it is a capability you grant. The difference is substantial, because a capability gets exercised when whoever holds it decides, not when you notice.
This post looks at what each permission concretely allows — and, above all, which few genuinely deserve attention.
It expands on the recommendation checking what your apps can do.
The hierarchy of permissions
They are not all the same, and treating them alike scatters your attention.
| Permission | Power | What it really allows |
|---|---|---|
| Accessibility | Maximum | Reading the screen and acting on your behalf |
| Device administration | Maximum | Changing system settings, locking, wiping |
| Installing from unknown sources | High | Installing software from outside the store |
| Drawing over other apps | High | Drawing on top of other screens |
| Contacts | High | The whole address book, other people’s data |
| Files and storage | High | Documents, photos, downloads |
| Microphone | Medium-high | Recording while the app is active |
| Camera | Medium-high | Images while the app is active |
| Location | Medium-high | Covered in a dedicated unit |
| Notifications | Medium | Reading the content of notifications |
| Calendar | Medium | Appointments, attendees, places |
| Network | Low | Practically every app has it |
The first three rows are of a different order of magnitude from the rest, and they are also the least discussed. The rest of this post concentrates there.
1. Confidentiality: what becomes readable
The permissions exposing other people’s data
It is the least considered aspect and one of the most relevant.
Contacts contain names, numbers, emails, and sometimes addresses and notes for dozens or hundreds of people. None of them took part in the decision, and none knows that data was shared.
The calendar contains appointments with the names of the attendees, the places and sometimes the notes. A work calendar describes an organisation: who you talk to, how often, about what.
Notifications, if an app has permission to read them, expose incoming messages from every other app — including verification codes.
The last row deserves prominence: an app with access to notifications can read second-factor codes as they arrive. It is one of the few ways a granted permission undoes one of the earlier recommendations.
The permissions exposing your own data
Files and storage: documents, photos, downloads. On some systems the permission is total; on others it can be limited to selected items.
Microphone and camera: they allow recording while the app is active. We come back to that shortly, because it is the site of a widespread misunderstanding.
What to watch for
- an app asking for permissions inconsistent with its function;
- a request arriving after an update, for a new feature;
- an app that stops working if you refuse a secondary permission.
What to do
Grant the minimum, use the limited options, revoke whatever has no obvious justification.
The misunderstanding about the microphone
It has to be addressed, because it is the most widespread worry and it is largely unfounded.
The belief: “my phone is always listening, because I see adverts for things I talked about”.
How things stand technically:
| Fact | Situation |
|---|---|
| The microphone requires an explicit permission | Yes |
| Its use is flagged by a visible indicator | Yes, on recent systems |
| Continuous listening would drain the battery noticeably | Yes |
| Transmitting continuous audio would generate detectable traffic | Yes |
| Investigations have looked for evidence of this | Yes |
| They found evidence of generalised continuous listening | No |
Why is the impression so strong, then? Because profiling based on other data is very effective: history, purchases, location, contacts, the searches of people nearby. The result resembles that of listening, and the coincidence is striking.
That does not mean the microphone permission is irrelevant: it means the real risk is a specific app with that permission, not generalised listening. And that is why the list of apps that can use it deserves a look.
2. Integrity: the permissions that allow acting
Here we move from observing to acting, and it is where the genuinely powerful permissions sit.
Accessibility
What it allows: reading everything appearing on the screen, and simulating taps and typing.
What that means concretely: an app with this permission can see passwords as you type them, read the messages you receive, and perform actions on your behalf inside other apps.
Why it exists: to make devices usable by people with visual or motor disabilities. It is a valuable and well-designed function.
The point: it is the system’s most powerful permission, and operating systems surround it with explicit warnings precisely for that. It should be granted only to recognised assistive tools and to nothing else.
Device administration
It allows system settings to be changed, requirements to be imposed on the screen lock, and in some cases the device to be locked or wiped.
It is the permission used by corporate management tools, and on a personal device there should be none you do not recognise.
Installing from outside sources
It allows an app to install others without going through the official store, bypassing the checks.
Drawing over other apps
It allows elements to be drawn on top of other apps. It has legitimate uses — chat bubbles, screen filters — and an improper one: showing a fake sign-in form on top of a real app.
3. Availability: marginal
An app with broad permissions can use battery and data, and in extreme cases make the device slow. It is a nuisance, rarely a security problem.
| Aspect | Impact of excessive permissions |
|---|---|
| Confidentiality | High, and it involves other people’s data |
| Integrity | Very high, but only for three or four permissions |
| Availability | Low |
The permission that exposes others: contacts
It deserves separate treatment, because it is the only case in this series where the decision directly concerns people who did not take it.
What an address book really contains. Not only names and numbers: emails, physical addresses, birthdays, personal notes, photos, family relationships indicated in the labels. For dozens or hundreds of people.
What can be done with it. Building a graph of relationships between people. If ten different users have the same number in their address book under the same name, that association is confirmed ten times — even if the person in question never used that service.
That is how profiles of people who are not users get built. It is a documented and discussed effect, and it is why some data protection rules treat the sharing of address books as a delicate subject.
The options available today:
| Option | When to use it |
|---|---|
| No access | The default choice for almost every app |
| Selected contacts | When a few need sharing |
| Full access | Messaging and telephony only |
The middle row is the most useful development: it lets sharing work without handing over the whole address book, and it is available on recent systems.
One consideration worth adding is not technical: the people in your address book gave you their number to talk to you, not so that it would end up in a commercial archive. It is argument enough to justify restraint, even with no identifiable risk.
What a permission does NOT allow
Useful for proportion, because many worries concern things the system prevents.
- An app cannot read another app’s data. Isolation between applications is a structural protection of mobile systems.
- An app cannot use the microphone or camera without permission, and on recent systems the use is flagged.
- An app cannot modify the operating system without administration permissions.
- An app cannot read another’s messages, except in the case of the notifications permission.
- An app does not remain after uninstalling: its permissions disappear with it.
The last row carries an important clarification: the permissions disappear, the data already collected does not. It stays where it ended up.
Why the exposure does not end with uninstalling
An aspect deserving clarity, because the instinctive reaction to an app that does not convince is to uninstall it.
What uninstalling solves: the permissions lapse, the app no longer reaches anything, it no longer runs in the background, it no longer transmits.
What it does not solve: the data already collected stays where it ended up — on the app’s servers, and with whoever received it from them.
| Element | After uninstalling |
|---|---|
| Permissions | Revoked |
| Future access | Stopped |
| Data on the device | Deleted, as a rule |
| Data already transmitted | Remains |
| Data passed to third parties | Remains, and multiplies |
| An account created in the app | Remains, and has to be closed separately |
The two highlighted rows define the limit of technical action. To go further there are the tools the data protection rules provide — a deletion request addressed to whoever handles the data — which are effective but require explicit initiative.
The last row is the most often forgotten: uninstalling an app does not delete the account you created inside it. If the app held a profile with your data, that profile stays active until the service closes it.
Hence a practical conclusion: uninstalling is a measure for the future, not a remedy for the past. And it is one more reason why the decision at the moment of the request counts more than any later correction.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Telling the powerful permissions from the ordinary ones |
| Skills | Recognising accessibility, administration and overlay |
| Secure Behaviour | Granting the minimum, and never accessibility without a reason |
Reference level: FL2 — Beginner.
Summary
- Permissions are not equivalent: three or four count far more than all the rest.
- Accessibility and administration are of a different order of magnitude.
- Contacts, calendar and notifications expose other people’s data.
- Generalised continuous listening finds no confirmation: the risk is a specific app, not the system.
One thing to do today. Look in the settings for the “accessibility” entry and see which apps use it. If there is one that is not an assistive tool, you have found the most important thing in this unit.
Related content
- Checking what your apps can do — the recommendation this expands on
- Consequences of an app collecting too much — the concrete effects
- Permission abuse — the techniques exploiting these permissions
- How to review granted permissions — what to do, in practice
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.
