Why the dialogs do not help
You have tapped Allow hundreds of times. The dialog appears mid-task, it is phrased vaguely, and refusing it feels like it might break something you were in the middle of doing.
That is not your failure of attention. The prompt arrives at the worst possible moment by design, and the wording tells you what is being requested without telling you what it exposes. "Allow this app to access your files" is technically accurate and practically meaningless.
This piece is the missing half: what each permission actually gives away once granted, in terms of what someone could learn about you.
For context on the scale: research on popular Android apps has found they request around eleven dangerous permissions on average. Dangerous is Android's own classification for permissions covering sensitive data, not a value judgement. Very few apps need eleven.
The high-exposure five
Location
The single most revealing permission on your phone, and it is not close.
People think of location as "where I am now". What is actually granted is a history, and a location history is a behavioural profile. From a few weeks of points you can derive:
- Home address, from where the device rests overnight
- Workplace, from where it rests on weekdays
- Commute, and therefore rough income bracket and transport habits
- Who you spend time with, by correlating co-located devices
- Places whose category implies sensitive information: a clinic, a place of worship, a lawyer's office
Research going back over a decade has consistently shown that a very small number of location points is enough to uniquely identify a person in a large dataset. Location is effectively an identifier even when the name is stripped.
Precise vs approximate. Precise puts you within a few metres. Approximate puts you within a few square kilometres, which is plenty for weather, regional pricing, or local content, and not enough to find your house. If an app offers the choice, take approximate.
Foreground vs always. Foreground means while you have the app open. Always means continuously, including at 3am. Almost nothing needs Always. Navigation while driving with the screen off is the genuine case. A retailer's app is not.
Reasonable to grant: maps during navigation, a weather app at approximate precision, a fitness tracker during a recorded activity. Refuse: anything that only wants it for content personalisation.
Microphone
Grants the ability to record audio when the app is running. Not just your voice: conversations near you, from people who never agreed to anything.
The popular fear here is that apps listen constantly to target ads. Repeated academic investigation has not found evidence of that at scale, largely because it would be an inefficient way to do something advertisers already achieve more cheaply through browsing and location data. Both modern platforms also show an indicator when the mic is live.
The real risk is more mundane: an app with a legitimate voice feature holds a permission that is broader than that feature, and audio handling in a small app is rarely audited.
Reasonable: calls, voice messages, deliberate recording, voice search you actually use. Refuse: anything where you cannot name the feature.
Camera
Same shape as microphone, plus a detail people miss. A photo carries EXIF metadata: the exact time, often GPS coordinates, and the specific device. An app with camera access and photo access can build a location history without ever requesting location.
Reasonable: the app's core function is capture, scanning, or video calling. Refuse: the camera is for an avatar you will set once. Use the photo picker instead, which grants access to one image rather than the camera.
Contacts
The permission that harms other people.
Your address book contains names, numbers, emails, and sometimes addresses and birthdays for hundreds of people who never installed the app and never consented. Granting it means handing over their data to make a decision about your convenience.
Uploaded address books are also how shadow profiles get built: records about people who have never used a service, assembled from the contact lists of people who have. If enough of your friends upload their books, a company knows a great deal about you without you ever appearing as a user.
Reasonable: a messaging app where finding contacts is the point, and even then it is worth asking whether it uploads or matches locally. Refuse: almost everything else. A checklist app has no business here.
SMS and call logs
Extremely revealing, and rarely necessary. Messages contain verification codes, financial alerts, and private conversation. Call logs reveal who you speak to, when, and for how long, which is metadata rich enough to reconstruct a social graph.
Google Play now restricts these to apps where SMS or calling is a core function, which has helped considerably.
Reasonable: your default messaging or phone app. Refuse: everything else, including apps that want to auto-read a verification code. Typing six digits is not a burden worth this.
The middle tier
Photos and media
Modern platforms have improved this substantially. Both Android and iOS now support granting access to selected photos only rather than the whole library.
Take that option every time it is offered. Full library access exposes every image you have, along with all the embedded location and timestamp data. Selected access exposes one picture.
Storage and files
Broad file access means documents, downloads, and anything else sitting on the device. Android's scoped storage narrowed this a lot, and most apps now use a picker that grants one file at a time.
If an app requests broad storage access in 2026, that is worth a moment's thought. The platform has provided a better mechanism for years.
Calendar
Reads your schedule: who you meet, when, where, and often the meeting title, which routinely contains sensitive detail. Write access lets an app add events, which is occasionally abused for spam.
Reasonable: something whose job is scheduling. Refuse: an app that wants to "help you plan".
Notifications
Not a data permission, an attention permission, so the calculus is different. The question is not what it exposes but whether the app has earned an interruption. Most have not. See notification fatigue and how to fix it for the full treatment.
Physical activity and sensors
Step counts, movement type, and on some devices heart rate. Useful for fitness apps, revealing in aggregate: activity data indicates sleep schedule, exercise habits, and health status.
The one nobody thinks about
Advertising ID. Not presented as a scary permission, and arguably the most consequential setting on the device.
Your advertising identifier is a persistent, unique ID that lets separate companies recognise the same device across different apps. Location from one app, purchases from another, and time-of-day from a third become one profile because they share the key.
Both platforms let you delete or restrict it. Android: Settings, Privacy, Ads, then delete the advertising ID. iOS: Settings, Privacy and Security, Tracking, and turn off Allow Apps to Request to Track.
This takes 30 seconds and does more for your privacy than refusing several individual permissions.
What the two platforms actually do differently
The permission model is not the same on Android and iOS, and the differences change what you should worry about.
Timing of the ask. iOS has always required a permission to be requested at the moment of use, with a system dialog that names the app's stated reason. Android historically granted broad permissions at install time and moved to runtime prompts from Android 6. Older apps that have not been updated can still behave in the older way, which is one reason an app with no update in three years is worth avoiding.
Duration. Both platforms now offer only this time for the sensitive permissions, which grants access for a single session and then revokes it. This is the correct default for anything you are unsure about, and almost nobody uses it because it is not the top option in the dialog.
Automatic revocation. Android automatically removes permissions from apps you have not opened in a few months, and iOS periodically reminds you which apps have been using location in the background. Both are genuinely useful and both are quiet enough that most people never notice them working.
Tracking. iOS App Tracking Transparency requires an explicit prompt before an app can track you across other companies' apps and websites. Android's equivalent is weaker: you can delete the advertising ID, but there is no per-app consent gate of the same kind.
Disclosure. Both stores now require a data-safety or privacy-nutrition-label section on the listing, filled in by the developer. Treat these as self-reported rather than audited, because they are, but a listing that declares sharing location with third parties has told you something useful regardless.
If you have already granted everything
Most people reading this have. Nothing is lost, because permissions are revocable and revoking them is retroactive in the sense that the app immediately loses access going forward.
What revoking does not do is retrieve data already collected. If an app has held your contact list for two years, that copy exists on someone's server and a settings toggle does not reach it. For anything you feel strongly about, the mechanism is a data deletion request under GDPR, the CCPA, or the app's own privacy policy, which is slower and considerably more effective than a toggle.
The practical order of operations is: revoke first because it is instant, then request deletion for the two or three apps you genuinely care about, then reset the advertising ID so future collection cannot be joined to past collection through the same key.
When a request does not match the app
An app doing one job has one reason to ask for anything. When the request and the job do not line up, there are three explanations and it is worth knowing which:
- A feature you have not found. Genuinely common, and checkable. Look for the feature.
- A bundled SDK. Advertising, analytics, and crash-reporting libraries are compiled into the app and collect on their own behalf. The developer may not have fully audited what they gather. This is the most common explanation for a simple app with a long permission list.
- Collection unrelated to any feature. Data as a product rather than a means.
This is one of the structural arguments for single-purpose apps: when an app does one thing, mismatches are obvious. A packing checklist asking for contacts is visibly wrong. A super-app asking for contacts has fourteen plausible reasons and you cannot evaluate any of them.
It also connects to how the app is funded. Apps monetised by advertising have a structural reason to want more data, which we cover in how free apps actually make money. The permission list is often the business model made visible.
The audit worth doing once a year
Budget an hour.
On Android: Settings, Privacy, Permission manager. This groups by permission rather than by app, which is the right way round. Open Location and look at the full list of apps that have it. The list is usually longer than expected.
On iOS: Settings, Privacy and Security, then the same permission-first view.
Work through the sensitive five first. For each app ask a single question:
What would break if I revoked this?
If you cannot answer, revoke it. Modern platforms handle denial gracefully: the feature stops, the app keeps working, and if something you actually use breaks you will find out within a week and can grant it back.
Then do the advertising ID.
What our own apps ask for
We build apps, so here is the disclosure rather than a claim about the industry.
PackPilot is a packing checklist. It does not need contacts, microphone, camera, SMS, or call logs.
PawDex tracks pet care. Walk tracking records a route, so it requests location for that feature, active while a walk is being recorded rather than continuously. It does not need contacts, SMS, or call logs.
Both publish a privacy policy on their own site describing what is stored. Neither sells user data or runs advertising. That last point is the reason the permission lists are short: there is no advertising SDK inside either app, and advertising SDKs are where most of the surprising requests in ordinary apps come from.
Verify that against the Play listing rather than this paragraph. That is the correct way to treat any company writing about its own privacy practices, including this one.
Related Reading
- Dark Patterns in Apps: A Field Guide covers the consent flows designed to make granting easier than refusing.
- How Free Apps Actually Make Money explains why so many apps want data they do not need.
- How to Choose an App You Will Still Use in a Year puts permissions into a wider evaluation.
- What Is a Single-Purpose App? covers why narrow scope makes mismatched requests obvious.
Sources and further reading: Android permissions overview, Android Developers, Cybernews analysis of dangerous permission requests in popular apps, NowSecure on mobile permission risk.
Frequently Asked Questions
Location, microphone, camera, contacts, and SMS. These expose either continuous data about where you are and what is happening around you, or data about other people who never agreed to anything. Popular Android apps request around eleven dangerous permissions on average, which is well beyond what most of them need.
Far more than where you are now. A location history reveals your home, your workplace, your commute, who you spend time with, and what kind of buildings you visit, including places that imply health or religious information. Research has repeatedly shown that a handful of location points is enough to identify a specific person.
Safer, not safe. Approximate location narrows you to roughly a few square kilometres, which is enough for weather or regional content and not enough to identify your address. If an app offers the choice, approximate is almost always the right answer.
Usually one of three reasons: a feature you have not found, an advertising or analytics library bundled into the app that collects independently, or data collection that is not tied to any feature you would recognise.
Modern Android and iOS handle denial gracefully. The related feature stops working and the rest of the app continues. Denying first and granting later if something genuinely breaks is a reasonable default strategy.
On Android, Settings then Privacy then Permission manager, which groups apps by permission rather than the other way round. On iOS, Settings then Privacy and Security. Both are worth an hour once a year.