The App You Installed Two Years Ago Isn't the Same App Anymore
You tapped "Allow" on the camera permission, maybe location, and moved on. That was the deal. A small act of trust, buried under two years of updates, that the app is still quietly collecting interest on.
App permissions can change with updates. Not dramatically, not with a warning banner, and often not with any prompt at all. The app gets new capabilities, and your old approval covers them.
This is how it works, why it happens, and what a few minutes of checking will actually tell you.
Why Your Old "Yes" Still Covers New Requests
Both Android and iOS use a permission system built around categories, not specific uses. When you approved "access to contacts" two years ago, you approved the contacts permission group. If an update expands what the app does with that group, it doesn't need to ask again. The permission is already granted.
On Android, this gets more specific. The platform groups permissions into "normal" and "dangerous" buckets. Normal permissions (knowing your timezone, checking network connectivity) are granted automatically at install, no prompt needed. Dangerous permissions (camera, microphone, precise location, contacts) require explicit user approval. Here's the part that actually stings: if an update adds a new dangerous permission that belongs to a group you already approved, Android can grant it silently. You approved the Location group as a single decision, not approximate and precise location as two separate choices. The update just takes the more capable one.
Apple's model is tighter but not airtight. iOS generally re-prompts for new permission types. But developers can expand the scope of data collected under an existing permission without triggering any new prompt at all. A fitness app with access to your Health data can add new data types to what it reads, as long as it stays inside the Health permission umbrella you already okayed.
The result is the same either way. The app grows. Your approval stays static.
A Concrete Example
Priya and Daniel both install the same productivity app on the same day. It asks for camera access to scan documents. They both tap "Allow" and forget about it.
Eighteen months later, version 4.0 drops. New feature: AI-assisted video summaries. The app now uses the camera permission to record short clips, not just snap stills. No new prompt appears on either phone. The permission was already there.
Priya checks her app permissions every few months, a habit she picked up after a podcast spiraled into mild paranoia. She sees the camera permission, taps through, and finds the app now lists video recording in its privacy policy. Fine, she decides. Moving on.
Daniel has never opened that settings screen. He doesn't know. The app has exactly the same access on both phones, and the only difference between them is awareness.
That gap is where the real privacy risk lives. Not in any single permission, but in the unchecked accumulation of them.
What People Assume That Isn't True
The most common wrong belief is that you would have been asked if something important changed. You wouldn't. App stores notify you about updates through changelogs, but developers write those themselves. A note about bug fixes and performance improvements is a perfectly valid entry that could accompany a new data collection feature, as long as the feature is disclosed somewhere in the privacy policy, which can update without any notification to you at all. That system is, to put it plainly, a joke dressed up as consumer protection.
A second wrong belief: revoking a permission will break the app. Sometimes it will. Often it won't. Many apps request permissions speculatively, asking for access they might use someday rather than access they need right now. A weather app that wants your contacts is not going to stop showing the forecast if you revoke it. Test it. The worst outcome is a single error message.
A third one worth naming: iOS is completely safe from this. iOS is better. Not immune. The App Store's privacy nutrition labels, those little data cards on each app's listing, can lag behind actual app behavior, and they're self-reported by developers. Apple audits them, but not in real time. Self-reported privacy disclosures are a bit like asking someone to grade their own homework.
The Audit That Takes Four Minutes
On an iPhone: Settings, then scroll to the app name, or go to Privacy and Security to see permissions sorted by type, with every app holding microphone access listed together. That second view is the useful one. Scan for anything that surprises you.
On Android: Settings, Apps, select any app, tap Permissions. Or go to Privacy, Permission Manager for the same sorted view. Android also flags permissions that haven't been used in the last 30 days. If an app hasn't needed a permission recently, it's worth asking why it still has it, and that's not rhetorical.
Found something odd? Revoke it and use the app normally for a day. You'll know within one session whether it matters.
One benchmark worth keeping in mind: a study of popular Android apps found that a meaningful share request permissions from three or more sensitive categories, location, microphone, contacts, camera, storage, when their core function plausibly requires only one. That's not malice in every case. It's often lazy development, or features planned and never shipped. Either way, you're carrying the exposure.
The Actual Principle Here
App permissions aren't a one-time decision. They're closer to a standing order you gave a contractor who keeps quietly expanding the scope of the job, one clause at a time, while you're not watching.
Trust doesn't transfer automatically from the app you installed to every version that follows it. The app that earned your approval and the app running on your phone after three years of updates might share a name, an icon, and a developer, but they don't necessarily share the same footprint inside your device.
Reviewing permissions once a year takes less time than a coffee. The apps with nothing to hide won't mind.