You Tapped "Deny" and Thought That Was That
You open your phone's settings, find that fitness app you barely use, and revoke its location access. Satisfying. Final. Except the app already grabbed your GPS coordinates six times this morning before you got around to it, stored them in its own local database, and synced them to its servers during your commute. The OS permission is gone. The data isn't.
That's the gap most people never see: revoking a permission controls future access, not past collection. And even future access has a few cracks in it.
What the OS Permission System Actually Controls
When you revoke an app's access to your microphone on iOS or Android, you're telling the operating system's permission gate to stop issuing that resource to that app. From that moment forward, any API call requesting microphone audio returns an error or silence instead of a live feed. That part works exactly as advertised.
The permission gate only covers resources that flow through the OS's declared permission framework, though. A lot of what apps know about you doesn't require a formal permission at all.
Take a concrete case. You revoke location permission from a weather app. Smart move. But that app can still infer your rough location from your IP address (no permission needed), from the Wi-Fi network names visible to the phone (network names have slipped through in various Android OS versions), and from the timezone your phone reports. None of those require the formal location permission you just revoked. The app loses precision. It doesn't go blind.
This is the architecture that actually matters: the OS permission model is a gatekeeper for specific hardware and data streams, not a general privacy shield. Treating it like the latter is a mistake almost everyone makes.
The Data That Already Left the Building
Picture two people, Marcus and Lena, who both installed the same navigation app two years ago and tapped "Allow" on location access without thinking much about it. Last month they both revoked it.
Marcus had opened the app maybe ten times total. The app has a thin, patchy record of his movements.
Lena used it daily for eighteen months. The app has a dense, continuous log: her home address inferred from where she parked every night, her office inferred from her nine-to-five stops, three medical clinics she visited, a divorce attorney's office. That history sits on the app company's servers. Revoking permission today doesn't delete a single row of it.
The revocation changed Lena's future exposure. Full stop. Whether that historical data gets sold, subpoenaed, or breached is now entirely outside her control, and no toggle in Settings touches it.
Cached Data and Local Storage: the Closer Problem
Beyond remote servers, there's the device itself. Apps routinely cache data locally: contacts they've read, photos they've scanned, location coordinates they've logged. When you revoke a permission, the OS stops the app from accessing that resource again. It doesn't flush the app's own storage.
On both iOS and Android, an app's private storage container (its sandbox) is off-limits to other apps and to the OS's permission system. The app owns what's in there. A photo-editing app that read your camera roll last Tuesday and stored thumbnails in its own local database still has those thumbnails after you revoke Photos access. It's less like unplugging a device and more like changing the locks after someone has already made copies of the floor plan. You'd have to delete the app entirely to actually clear it, and on Android, residual files can sometimes survive depending on where the app stored them.
This is where the permission model reveals its design philosophy: it was built to regulate access channels, not to enforce data minimization after the fact.
What the Permission Model Was Never Designed to Do
The most common mistake is assuming that "ask every time" or "only while using" settings on iOS and Android solve the problem. They reduce ongoing exposure significantly, which is genuinely valuable. But they don't retroactively reach into cached data, they don't cover the permission-free inference routes, and they don't touch anything already sitting on remote servers.
Also worth knowing, and almost nobody talks about this: some third-party SDKs, the analytics and advertising libraries embedded inside many apps, often without the app developer's full awareness of their behavior, have their own data collection logic that can operate somewhat independently of the host app's code. Revoking permissions from the app doesn't necessarily interrupt what an embedded SDK already knows or has already sent. The app you're punishing may not even be the culprit.
What Actually Limits the Damage
Few controls are as effective as the ones applied before data is collected rather than after. Think of it as the difference between a bouncer at the door and a cleanup crew the morning after.
On iOS, the App Privacy Report (Settings, under Privacy and Security) shows you which apps have actually used which permissions and how often. If an app accessed your location forty times in the last week and you only opened it twice, that's a signal worth acting on before the data pile grows any larger.
Android's Permission Manager gives a similar view, with a dashboard showing recent permission usage. If you're seeing accesses you don't remember triggering, those are worth investigating before you shrug and move on.
Deleting an app removes its future access and wipes its local storage sandbox (on iOS, reliably; on Android, mostly). Combined with revoking permissions before deletion, this is the most complete reset available to a regular user. For apps you want to keep, the practical floor is: grant permissions only while the app is in use, check the privacy report every few months, and treat any app requesting permissions it has no obvious need for (a flashlight app wanting contacts, a recipe app wanting the microphone) as one that has already told you something about its intentions.
The Honest Position
The OS permission system is a genuinely useful tool. The "ask every time" options on modern iOS and Android are materially better than the blanket approvals that were standard a decade ago. None of that is nothing.
But there's an uncomfortable structural reality: this system was designed by the same companies that sell advertising and run app stores with commercial interests in data flows. It was built to give users meaningful control over specific channels, not to retroactively protect data that already moved. Expecting it to do the latter is a category error, not a reasonable extension of what the feature promises.
By the time most people think about revoking a permission, the collection window they were worried about has already been open for months. The revocation is still worth doing. Just go in clear-eyed about what you're actually closing, because it's a lot narrower than the Settings UI implies.