Every installed app asked for something, and in most cases it got a yes.
Not out of carelessness: the request always arrives at the wrong moment — while you are opening the app to use it, with your attention on the goal and not on the question. The “allow” button is the quickest way to get where you were going.
The result, after a few years, is a list nobody has ever reread, describing a device far more open than its owner imagines.
What this recommendation says
Recommendation R13 establishes that the permissions granted to applications should be reviewed periodically, and that each new request should be weighed rather than accepted out of habit.
Permissions are the authorisations through which an app reaches the device’s functions and data: camera, microphone, contacts, files, notifications, location, and more.
What it is not. It is not a recommendation against apps. Almost every app installed from official stores is legitimate, and many need the permissions they ask for in order to work. The recommendation concerns excess, not the existence of permissions.
Scope. Phones and tablets first of all, where the permission system is granular. It applies to browser extensions too, which are often the most neglected point.
Why it matters
A permission granted is not an isolated event: it is a permanent condition.
| Permission | What it allows | When it is justified |
|---|---|---|
| Contacts | Reading your entire address book | Messaging, telephony |
| Microphone | Recording audio | Calls, voice notes, recording |
| Camera | Capturing images | Photos, video calls, scanning |
| Files and photos | Reading your archive | Galleries, editors, file managers |
| Location | Knowing where you are | Maps, weather, transport |
| Background activity | Working while closed | Syncing, alerts |
| Accessibility | Seeing and controlling the whole screen | Assistive tools for disability |
The last row is the most important in the whole unit. The accessibility permission is the most powerful an app can obtain: it allows the contents of the screen to be read and actions to be taken on the user’s behalf. It exists for an excellent reason — making devices usable by people with disabilities — and that is why it should only be granted to tools genuinely serving that purpose.
The second row deserves a note too: the contacts permission exposes data that is not yours. Names, numbers and addresses of other people, who took no part in the decision.
A concrete example
Mark installs an app to edit photos. On first launch the app asks for access to his photos — reasonable — and then to his contacts, to “make sharing easier”.
He accepts both, because the second request arrives straight after the first and seems part of the same flow.
From that moment a photo-editing app has his entire address book: names, numbers, emails, and in some cases addresses and notes. It is not illegal, it is not hidden, and it is written in the privacy notice nobody reads.
The point: the request was reasonable only halfway, and the second half went through with the first.
When to apply it
- At the moment of the request. It is the best opportunity: refusing now costs less than revoking later.
- After installing something new, to check what it obtained.
- Periodically, to review the accumulated list.
- Before uninstalling an app, to know what it had.
- On children’s devices, where the apps are many and the requests get accepted without assessment.
- When an app changes owner, news that sometimes appears in the updates.
- On browser extensions, which hold very broad permissions and get forgotten.
How to apply it
- Open the list by permission, not by app. Both systems let you see “which apps have access to the microphone”: it is far more revealing than the list by app.
- Start from the three most sensitive: microphone, camera, contacts. They carry the greatest potential for exposure.
- Check the accessibility permission and make sure it is granted only to tools that genuinely need it.
- Revoke whatever has no functional reason. The criterion is simple: could this app do its job without it?
- Use the intermediate options. Many systems allow access to selected photos instead of the whole gallery, or use only while the app is open.
- Review the browser extensions, and remove the ones you do not use.
- Turn on automatic revocation for unused apps, where the system offers it.
Common mistakes to avoid
- Accepting in order to reach the content. It is the mechanism nearly all excessive collection rests on.
- Never looking at the list. Permissions accumulate for years with nothing bringing them back to attention.
- Granting accessibility lightly. It is the most powerful permission and it gets requested by apps that do not need it.
- Giving access to the whole gallery when a few photos would do.
- Overlooking browser extensions. They often have permission to read and change everything you see online.
- Trusting an app because it is in the official store. The checks exist and are useful, but they do not replace weighing the permissions.
- Ignoring company apps’ permissions on a personal device.
The three questions that settle every doubt
Facing a permission request, you do not need to understand the technology. Three questions are enough.
1. Could this app work without it? A photo-editing app needs the photos. It does not need the contacts. If the function is clear, the answer is immediate.
2. Does the permission need to be now or always? Many apps need something only while you use them. If the system offers “while using the app”, that is almost always the right answer.
3. What happens if I say no? In most cases: nothing, or a secondary function is unavailable. Refusing is reversible in two taps, whereas the data collected does not come back.
Those three questions cover practically every situation, and they take five seconds.
Why the list grows on its own
It is worth understanding the mechanism, because it explains why a review is needed and why “being careful” is not enough.
Every new app asks for at least one permission. Quite a few get installed in a year, and each adds an entry.
The request arrives at the worst moment. You are opening the app to use it: attention is on the goal, and the consent button is the shortest route.
Refusing has an immediate cost, consenting a deferred one. If you say no, maybe something does not work now. If you say yes, maybe something happens in months. It is an asymmetry pushing towards yes, and it has nothing to do with carelessness.
Nothing brings the permission back to attention. There is no reminder, there is no visible expiry, there is no natural moment to review.
Uninstalled apps leave traces in the habit. Even when the list gets shorter, the practice of accepting stays.
Hence the operational conclusion of this recommendation: the problem is not a wrong decision, it is the absence of a moment in which to decide. The periodic review exists precisely to create one.
The case of browser extensions
They deserve a mention in the recommendation itself, because they are the most neglected point and one of the most relevant.
An extension is not a standalone app: it runs inside the browser, which is the program seeing everything you do online. The typical permission — “read and change your data on the sites you visit” — includes the sites where you type credentials.
Three points of care worth as much as the whole review of mobile apps:
Remove the ones you do not use. They are almost always the majority: installed for one day’s need and left for years.
Limit access to the sites where they are needed, where the browser allows it. It is a little-known and very effective option.
Check they are still maintained. An extension sold to a new owner inherits the permissions already granted, and it is a case documented several times.
How this connects to the Cyber Welfare Framework
| Pillar | How it contributes |
|---|---|
| Awareness | Understanding that a permission is a permanent condition, not an event |
| Skills | Reading the list by permission and using the intermediate options |
| Secure Behaviour | Weighing at the moment of the request instead of accepting to reach the app |
Digital maturity levels.
- FL1 — Basic. Permissions accepted out of habit, the list never looked at.
- FL2 — Beginner. The list has been reviewed at least once; the obviously pointless permissions have been revoked.
- FL3 — Autonomous. New requests get weighed; the intermediate options get used; accessibility is under control.
- FL4 — Skilled. Periodic review across every device, browser extensions included; automatic revocation on.
- FL5 — Expert-Guide. You help others — particularly families — set permissions and explain why.
R13 completes R12: there two specific permissions were examined, here the whole system.
How to check you are applying it correctly
- How many apps have access to the microphone on my phone right now?
- Is there any app with the accessibility permission that is not an assistive tool?
- How many extensions does my browser have, and what can they read?
Quick checklist
- ☐ The permission list reviewed at least once
- ☐ Microphone, camera and contacts checked first
- ☐ No unnecessary app with the accessibility permission
- ☐ Access to selected photos rather than the whole gallery, where possible
- ☐ Browser extensions reviewed and reduced
- ☐ Automatic revocation for unused apps on
- ☐ I weigh new requests instead of accepting them
For an overall measure of where you stand, you can take the digital resilience self-assessment.
In short
Permissions are not a technical problem: they are a problem of attention at the wrong moment.
The request arrives when you want to use the app, and saying yes is the shortest route. Nobody goes back to reread it, and in a few years the device becomes far more open than anybody would have deliberately chosen.
The remedy is simple and produces an immediate effect: open the list, look at it, shorten it. Ten minutes, and the permissions that remain are the ones you decided on.
Something to think about. If you opened the list of apps that can use your microphone right now, how many would you expect to find — and how many are actually there?
Explore this recommendation
- Impact of excessive permissions — what each authorisation concretely allows
- Consequences of an app collecting too much — the real effects, and the myths to dispel
- How to review granted permissions — the procedure, system by system
- Signs an app is collecting data — what to notice and what is not a clue
- How mobile permissions work — the mechanism behind the requests
- Permission abuse — the techniques exploiting permissions granted
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.
