Reading an app's privacy label properly

Every app on both stores now carries a summary of what data it collects. Most people scroll past it, and the ones who read it come away with a vague impression rather than a decision. That is a waste, because the label answers a specific question if you know which parts to read.

App permissions are the capabilities an app asks the operating system for once installed — camera, location, contacts — and they are related to but distinct from the privacy label, which is a declaration made by the developer about what data leaves the device, published before you install. The permissions are what the operating system asks you for afterwards. Reading the label properly changes which app permissions you are ever asked for.

The three questions the label answers

Every category on the label carries the same three pieces of information, and the second and third matter more than the first.

Is it collected? Does this data leave your device at all. Anything processed locally and never transmitted is not collected — which is why "works offline" and "collects nothing" tend to travel together.

Is it linked to you? Whether the data is tied to your identity or a persistent device identifier. Unlinked usage statistics are a genuinely different thing from the same statistics attached to an account.

Is it used to track you? Whether it is combined with data from other companies for advertising or measurement. This is the strongest signal on the whole label, and it is the one people skim past.

Collected, linked, and used for tracking are three separate questions. An app can collect a lot without linking any of it, and an app can collect little and track you with all of it.

What to look for first

Four checks, in the order that rules out the most.

1. Look at "Data Used to Track You" before anything else. If it is empty, most of the concerning cases are already excluded. If it lists items, the app is part of an advertising or measurement network.
2. Compare the collection against the app's job. A calculator collecting location is a mismatch. A maps app collecting location is not. The question is never "is this a lot" but "does this follow from what it does".
3. Check for contacts, photos and location specifically. These three are the categories people care about most in practice and are most often collected without an obvious purpose.
4. Note whether identifiers appear. A device or advertising identifier is what makes everything else joinable, and its presence changes the weight of the other categories.

Where the label is weaker than it looks

Being realistic about it prevents both false confidence and unnecessary suspicion.

• It is self-declared. The developer fills it in. Stores do audit and enforce, and the primary check is still the developer's own honesty and — more often — their knowledge of what their own SDKs do.

• The categories are broad. "Usage Data" covers a screen view and a detailed behavioural profile equally.

• It does not say who receives it. Data collected by an app may pass to analytics, advertising or attribution companies, and the label does not name them.

• It does not describe retention. Nothing indicates how long anything is kept.

• It can be out of date. Labels are updated at submission, so a label describes a version rather than a company's current practice.

What this adds up to: the label is a good filter and a poor guarantee. An app declaring no collection is very likely telling the truth, because the claim is falsifiable and cheap to check. An app declaring a lot is telling you something real about its business model.

What the label does not cover at all

Three things sit entirely outside it, and they are where most real problems live.

What the app shows you. A label describes data flowing out, not content coming in. An app that collects nothing and fills your screen with manipulative prompts is fully compliant and still worth avoiding.

Security of what is collected. Declaring that data is collected says nothing about how it is protected. A breach discloses exactly what the label promised would be collected — and the label was accurate throughout.

What happens if the company is sold. Data collected under one privacy policy can end up under another. This is legal, common, and invisible in any label, and it is the strongest argument for preferring apps that collect nothing over apps that promise to handle collection well.

The third point is worth sitting with, because it changes what "trust the developer" means. You are not only judging the people who wrote the app today; you are judging what the data would become in someone else's hands. An app holding nothing is the only version of that question with a permanent answer, which is the practical reason to prefer local processing where the feature allows it.

Testing the claim yourself

Two checks that beat reading anything.

Airplane mode. Turn it on and use the feature you care about. If it works, that part runs locally, and no privacy policy is needed to establish it. This is the single most useful five seconds available.

The permission prompts. What an app actually asks for at runtime, and when. An app requesting location on first launch before showing you anything is telling you what it is for.

Together these tell you more than a policy document, because they test behaviour rather than intent.

How should you handle app permissions after installing?

App permissions are the second half of the decision, and four rules cover them.

Grant the minimum app permissions that make the feature work. "While using the app" rather than "always", approximate location rather than precise, selected photos rather than the full library. These options exist and most people take the first option offered.

Watch when the request appears. A request in context — after you tap "add a photo" — is a good sign. A batch of requests at launch, before you have done anything, is a request for capability rather than for a feature.

Refuse first, and see what breaks. Most apps continue to work with the permission denied, losing one feature. If the app refuses to function at all without something unrelated to its job, that is the finding.

Review periodically. Both platforms list app permissions per app and per category, and the reports of background access are worth reading rather than dismissing.

When to just not install it

Three situations where the label ends the decision.

Tracking declared by an app with no advertising. If there are no ads and data is used for tracking, the data is the product.

Collection wildly beyond the function. A wallpaper app collecting contacts, a torch collecting location.

A category that cannot be undone. Health, financial and precise location data are qualitatively different from usage statistics, and a leak of them is not recoverable in the way a password is.

For anything holding money or credentials, the standard is higher still — a wallet or banking app's list of app permissions where the list should be short and every item obviously necessary.

More reviews in reviews, comparisons in comparisons, and picks in best tools. Apple documents the label categories and Google the equivalent data safety section.

The short version

Read "Data Used to Track You" first — if it is empty, most of the concerning cases are gone. Then check whether what is collected follows from what the app does, and whether identifiers appear that make the rest joinable.

Treat the label as a filter rather than a guarantee: it is self-declared, its categories are broad, and it does not say who receives the data or for how long. Then test the claim in airplane mode, grant the narrowest permission that makes the feature work, and refuse first to see what actually breaks.