App Permissions and Data Minimisation: A RAJA89 Guide

How a Permission Is Actually Granted

Modern mobile operating systems do not let an app simply take what it wants. A permission is a gate the operating system controls, and three things have to line up before data flows.

1. The app declares the permission in its manifest or its App Store listing. On Android, applications must declare permissions such as ACCESS_FINE_LOCATION or READ_CONTACTS; on iOS, the app calls a system interface that triggers a prompt.
2. The system asks you for the dangerous ones, normally the first time the app tries to use the capability. Some permissions are granted automatically at install, which is why reading app permissions after the fact matters.
3. The app receives the data or loses access, depending on your answer. On both platforms you can revoke later, and revocation takes effect immediately.

Two structural points follow, and they explain most of the frustration people have with permission settings.

Not everything is gated. Permissions control access to device capabilities. They do not control what an app learns because you signed into it, what the company's server already holds from previous sessions, or what a third-party software development kit inside the app collects on the app's behalf.

Revocation is not retroactive. Turning off location access today stops future collection. It does not delete the location history already uploaded, and it does not unwind data that was shared onward. That part is a data rights question, not a settings question.

The Permissions That Carry Real Risk

Exposure is not evenly distributed. Some permissions reveal a single sensor reading once. Others hand over a durable archive, or data about people who were never asked.

Contacts is the one permission where your decision gives away other people's data. Nobody in your address book agreed to that upload, and they cannot find out it happened. An app offering to "find your friends" wants the entire book, so it can match it against its user base and reconstruct a social graph nobody consented to.

Accessibility services are the most powerful thing on the phone. They exist so screen readers can read and act on everything, which is exactly why they are dangerous elsewhere: granted to a non-assistive app, they expose every screen and permit taps on your behalf, including approving a payment. A small number of banking trojans have spread this way. If an app you do not recognise appears on that list, remove it immediately and change your banking passwords.

Notification access is a credential path. One-time login codes arrive as notifications. An app that can read notifications can read those codes, which is why this permission deserves the same suspicion as accessibility access.

One honest limitation on all of this: denying a permission does not stop an app from learning the same fact by other means. A shopping app denied location access can still infer your general area from your IP address, and a delivery app can ask you to type an address. Permissions reduce precision; they do not create blindness.

The App Is Rarely the Only Recipient

You install one app. Your data goes to several companies.

Most apps are assembled partly from third-party components - analytics libraries, crash reporters, advertising networks, attribution tools, customer-support widgets - bundled by the developer. Each runs inside the same app, with the same permissions your grant gave. A weather app with location access and a crash-reporting library may be sharing your coordinates with a company the developer has never met, under terms you have never seen.

This is normal engineering practice and not automatically malicious, but it has two consequences worth internalising.

• The privacy label describes the app, not the SDK inside it. A developer who answers "data not linked to you" is describing what their own code does, and often relying on each vendor's own claims about theirs.
• Removing the app stops its SDK, and not the vendor's existing records. Once an identifier and a location have been sent, deleting the app is a local action.

What genuinely helps: prefer apps with a paid tier, because a subscription is a revenue model that does not require your data; prefer apps whose privacy disclosures name the categories and purposes specifically rather than using boilerplate; and treat "free and unlimited" as a statement about how the service is funded. See data rights for what you can demand from the vendors you never chose.

Reading Privacy Labels With Scepticism

Apple's App Store privacy labels and Google's Data safety section are genuinely useful and structurally limited. Understanding both halves makes them worth reading.

What they are good for

• Comparing two apps that do the same thing, which is the decision you are actually making.
• Spotting an obvious mismatch: a torch app that declares it collects financial information is worth avoiding on that alone.
• Finding out whether a developer declares that data is used for tracking across other companies' apps - the category that matters most.

Where they are weak

• Self-declared. The developer writes the label. Apple and Google audit selectively and enforce in cases that come to light, but the label is a claim rather than a measurement.
• Categories are broad. "Identifiers" covers an advertising ID, an account email and a device fingerprint, which have very different consequences.
• SDK behaviour is often one level removed, as described above.
• Labels describe declared practice, not observed behaviour. Independent research has repeatedly found apps whose network traffic did not match their label, and enforcement follows slowly.

The practical reading: use the label to rule things out, not to feel reassured. A label that declares nothing is not proof of nothing.

A Permission Audit Worth Doing Twice a Year

Fifteen minutes, in this order. The first step is what makes the outliers visible.

1. Read the list by permission, not by app. On iOS, Settings then Privacy and Security has a section per category, each listing every app that holds it. On Android, Settings then Security & privacy then Privacy then Permission manager. Going app by app hides the pattern; going permission by permission shows you that nine apps have your microphone.
2. Downgrade location. Anything that is not navigation, transport, delivery or fitness goes to Approximate, While Using, or Never. Clear any background grant you did not make deliberately.
3. Switch photo access to selected items, or move to apps that use the system photo picker, which requires no permission because the system hands over only the image you chose.
4. Revoke microphone and camera from anything with no recording feature you actually use. These are usually leftovers from something you tried once.
5. Check the special access lists. Accessibility, notification access, all-files access, usage access, display over other apps, device admin. They should be short, and you should be able to explain every entry.
6. Uninstall what you do not use. The strongest single step, because it revokes everything at once. Android auto-revokes permissions for long-unused apps but keeps them installed; iOS "Offload Unused Apps" keeps the app's data, so it is storage housekeeping rather than privacy work.

Repeat the audit after a major operating-system upgrade, because new permission categories appear and defaults sometimes reset. And remember the boundary: revoking stops future collection and does not delete what was already sent. That is a separate exercise.

Account Controls Are a Separate Layer

Permissions govern the device. Account settings govern what the service keeps, and they are where the durable decisions happen.

• Auto-delete activity. Major platforms let you set web, app, location and video history to delete automatically after three or eighteen months rather than being retained indefinitely. This is the single most consequential account setting available, because it changes what exists rather than what is displayed.
• Ad personalisation. Worth switching off, and much weaker than people assume: it changes which advertisement you see, not how much is collected or how long it is kept. Do not let it stand in for auto-delete.
• Sign-in sessions. Review the list of devices signed into the account, with locations and last activity. This is where an unwanted session shows up.
• Connected apps. Every "Sign in with..." grant gives an app its own ongoing access. The list is usually years old and full of experiments. Revoke what you do not use, and note that revoking in the app is not enough - the grant lives with the platform account.
• Data download and deletion. Most platforms provide an export and a delete option. Understanding what they cover is worth an hour, and it is the practical route into the rights described in exercising your data rights.

Minimisation as the Organising Principle

All of this reduces to one question asked at every prompt: what is the smallest grant that makes this feature work right now?

One-time rather than always. Approximate rather than precise. One photo rather than the library. A typed phone number rather than the address book. Declining is rarely final - you can grant later in Settings when you discover you need it, and most people never do.

The costs are real and worth naming. Approximate location breaks some store locators and pickup points. Selected-photos access means re-picking each time. Denying contacts means typing numbers. Judge it per app and per feature, not as a blanket policy, and remember that a friction cost paid once a month is usually a bargain.

Minimisation also does not protect what you type in voluntarily, is not retroactive, and is no substitute for a hardened browser and device. What it does is compound. Data kept out of a company's logs cannot appear in its next breach notification, cannot be bundled into a dataset when the business is sold, and cannot be handed over when disclosure is legally compelled. That is a durable benefit, and it is the reason this chapter exists.

Questions readers ask about this page

Back to top ↑