The techniques in this family have a characteristic that sets them apart from every other in the series: they get around no protection at all.
The permission system works correctly, shows the requests, asks for confirmation. The protection is passed because the user turns it off — convinced, distracted, or placed in a position where they feel they cannot do otherwise.
So it is a family of persuasion techniques more than digital ones.
It expands on the recommendation checking what your apps can do.
1. The legitimate app that asks for too much
How it works. A real, working app asks for permissions exceeding its function, justifying them with plausible benefits: “to suggest content”, “to improve your experience”, “to make sharing easier”.
Why it works. The app really does what it promises, and the request is framed as an improvement. There is nothing visibly wrong.
What it gets. Data used for profiling or passed to third parties. It is by far the most frequent case, and it is largely legal.
The specific defence. The recommendation’s three questions: would the app work without it? Is it needed now or always? What happens if I say no?
2. The nested request
How it works. A necessary permission gets asked for first, and immediately afterwards an unnecessary one, in the same sequence.
Why it works. The first yes creates momentum: the second request arrives at a moment when critical attention has already dropped.
What it gets. A permission that, asked in isolation, would have been refused.
The specific defence. Treating each request as independent. One yes does not imply the next.
3. Winning accessibility
It is the most serious technique in this family, and it deserves space.
How it works. The app asks the user to turn on the accessibility permission, guiding them step by step through the settings. The justification is always plausible: “to protect your device”, “to block advertising”, “to make this feature work”.
Why it works despite the warnings. The system shows an explicit warning, but the user has already decided to install that app and considers it trustworthy. The warning gets read as a formality.
What it gets. The broadest control available: reading the screen and acting on the user’s behalf. From there it is possible to see typed credentials, read messages, and perform actions inside other apps.
The specific defence. One rule with no exceptions: accessibility is granted only to assistive tools for disability. Any other justification, however convincing, does not warrant that permission.
4. The deceptive overlay
How it works. An app with permission to draw over others shows a fake sign-in form on top of a real app. The user types their credentials believing they are in the legitimate app.
Why it works. Visually it is indistinguishable: the screen underneath is the real one.
What it gets. Credentials typed voluntarily.
The specific defence. Check which apps have the overlay permission. Recent systems greatly limit this possibility while sensitive data is being entered.
5. The app that changes after installation
How it works. An honest and useful app accumulates installs. Then it gets sold, or receives an update introducing collection features. The permissions were already granted.
Why it works. There is no moment of asking: the consent was given to the earlier app.
What it gets. Access to everything already authorised, for a potentially enormous number of users.
The specific defence. The periodic review, which is the only thing catching a change that happened in silence. And, for browser extensions, checking they are still maintained by the same author.
6. The app from outside the store
How it works. An app gets distributed outside the official stores — through a link, a message, a site. To install it, the permission to install from outside sources has to be turned on.
Why it works. The justification is nearly always a good one: an early version, an app not available in your area, a specific tool.
What it gets. An installation that passed no checks at all.
The specific defence. Do not turn that permission on. It is the only case in this family where the rule can be absolute at no meaningful cost to most people.
The overall picture
| Technique | Frequency | Severity | What stops it |
|---|---|---|---|
| A legitimate app asking for too much | Very high | Low-medium | The three questions |
| The nested request | High | Medium | Weighing each request on its own |
| Winning accessibility | Medium | Maximum | A rule with no exceptions |
| The deceptive overlay | Low | High | Checking the special permissions |
| An app that changes afterwards | Medium | Medium-high | The periodic review |
| An app from outside the store | Medium | High | Not turning that permission on |
The two highlighted rows set the priorities: one rule never to break, and one habit to maintain. Everything else follows from there.
The recurring wordings in requests
Since these techniques rest on persuasion, the recurring wordings are worth recognising. They are not proof of bad faith — many honest apps use them — but they are the points where it is worth pausing.
| Wording | What it conceals |
|---|---|
| “For a better experience” | No specific function: it is a generic justification |
| “To suggest content for you” | Profiling |
| “To make sharing easier” | Access to your address book |
| “To protect your device” | It often accompanies an accessibility request |
| “Some features will not be available” | Pressure, without saying which |
| “Allow to continue” | A permission presented as compulsory |
| “Just this once” on a system screen | Confusion between a system option and the app’s own text |
The fourth row is the most important to recognise: an accessibility request justified by security is an inconsistency, because that permission is for accessibility, not for protection.
The fifth and sixth describe the same pressure: presenting an optional permission as necessary. The way to check is simple — refuse and see what actually happens.
The last deserves attention because it is subtle: some apps write text imitating the system’s options, to steer the choice. The real options are only the ones in the system window, recognisable by its styling.
Why these techniques work
It is worth looking at the common mechanism, because it is the same one recurring throughout the series.
The request arrives at the worst moment. When you are trying to do something, not when you are assessing security. Attention is on the goal.
Refusing has an immediate and certain cost, consenting a deferred and uncertain one. It is an asymmetry naturally pushing towards yes.
The justification is always plausible. No request says “I want your data”: it says “to serve you better”.
There is no moment of checking. Once granted, nothing brings the permission back to attention — except a voluntary review.
Hence why this recommendation insists on two apparently trivial things: pausing five seconds at the moment of the request, and looking at the list now and then. They are not generic advice: they are the only two countermeasures to the structure of the problem.
What does not belong to this family
System vulnerabilities. Defects allowing permissions to be bypassed exist and get fixed by updates. They are another family, and the defence is keeping the device updated.
Apps installed by other people on your device. It is a question of physical access, covered in the units on screen locking.
Declared and permitted collection. An app collecting what it declared is not abusing anything: it is doing what you consented to. The remedy is revoking, it is not an incident.
The context these techniques arrive in
An element worth isolating: a permission request almost never arrives on its own. It arrives inside a path, and the path counts as much as the request.
| How you got to the app | Level of attention |
|---|---|
| You searched for it yourself in the store | Low |
| Somebody you trust recommended it | Low |
| You found it following a link in a message | High |
| Support that contacted you suggested it | Maximum |
| You installed it to solve an urgent problem | High |
| It appears in an advert promising a great deal | High |
The two highlighted rows describe the most serious scenario in this family: somebody contacting you, presenting themselves as support — from a service, a bank, an operator — and guiding you to install a tool “to fix the problem”.
That tool asks for accessibility, and the request arrives at a moment when a person is looking for help and trusts whoever is giving it.
The rule in this case is clear: no legitimate support asks you to install a remote-control app during a call you did not request. If it happens, you end the call and dial the service’s official number yourself.
It is worth adding that this scenario disproportionately affects people less used to digital tools — and it is the case where talking about it beforehand, in the family, is worth more than any setting.
Why this family is the hardest to defend against
A closing consideration that holds for the whole series.
Against the other families of threat there are automatic defences: encryption protects without you doing anything, a second factor stops whoever lacks the code, an update closes a vulnerability.
Not here. The system has already done everything possible: it isolates the apps, requires consent, makes the powerful permissions inconvenient, shows explicit warnings, flags use in real time.
And then it asks a person to decide. At that point the protection depends on an answer, and no technology can give it in their place.
| Defence | Who exercises it |
|---|---|
| Isolation between apps | The system |
| The consent request | The system |
| Warnings on powerful permissions | The system |
| Usage indicators | The system |
| The answer to the request | You |
It is why this unit contains no settings to turn on but two behaviours: pausing five seconds at the moment of the request, and looking at the list now and then.
And it is also why, in the Cyber Welfare Framework, this recommendation belongs as much to the Skills pillar as to Secure Behaviour: knowing what a permission does is not enough, it takes the habit of asking at the right moment.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Understanding that nothing is bypassed here: a yes is obtained |
| Skills | Recognising the nested request and the winning of accessibility |
| Secure Behaviour | An absolute rule on accessibility, and the periodic review |
Reference level: FL3 — Autonomous.
Summary
- These techniques do not bypass the system: they obtain a consent.
- The most serious is winning accessibility, and it stops with a rule that has no exceptions.
- An app can change after you gave it the permission: only the periodic review catches that.
- The structure of the problem is that the request always arrives at the worst moment.
One thing to do today. Decide now, calmly, what you will answer the next time an app asks you to turn on accessibility. The decision taken now is worth more than the one taken while you are trying to get something to work.
Related content
- Checking what your apps can do — the recommendation this expands on
- Impact of excessive permissions — what these techniques obtain allows
- Signs an app is collecting data — how to recognise them before and after
- How to review granted permissions — the review that catches the changes
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.
