Reading Your Phone's Privacy Dashboard
Both major mobile platforms keep a log of when an app actually used a sensitive capability — microphone, camera, location, contacts, photos — as distinct from merely having permission to. That log is the only source in this whole subject that comes from the operating system rather than from an app’s description of itself, which makes it the most trustworthy thing available to you. It is also narrower than people expect.
Finding it takes a minute. Interpreting it correctly takes knowing what it does not cover.
Where it lives
The names differ and the location is roughly the same on both.
On Android it is the Privacy Dashboard, in the privacy section of Settings. It shows a timeline of permission use over the past day or so, filterable by permission and by app, and it also lists which apps hold each permission.
On iOS the equivalent is App Privacy Report, in the privacy and security section, and it must be switched on before it starts recording. Once running it shows sensor access per app and — usefully, and uniquely — the network domains apps contacted.
Both also expose the top-level indicator dots in the status bar: a small marker while the microphone or camera is active. That is the real-time version, and noticing it is often how people end up looking at the log in the first place.
Turn the iOS report on now if it is off. It records nothing retroactively, so the value only starts accumulating from the moment you enable it, and the first useful reading is a few days later.
How to read it without over-reading it
The log is a record of access events. Turning that into a conclusion requires care.
Correlate with what you were doing. Microphone access at the moment you tapped a voice button is the feature working. Microphone access while the app was in the background and you were asleep is a question. The timeline is what makes that distinction possible.
Expect attribution surprises. Dictation shows up as the keyboard or the system, not the app you were typing into — see what your keyboard can see. Photo picker use may be attributed to the system picker rather than the requesting app, because on modern platforms the app never touches the library. Both of these look alarming and are not.
Frequency matters more than presence. One location read on launch is different from continuous sampling. The dashboard shows counts and times, which is exactly the resolution needed.
An unused permission is a permission to revoke. The most actionable output of the whole exercise is the list of capabilities an app holds and has never used. Revoke those; the app will prompt again if it ever needs them, per what a permission prompt actually grants.
The network section is the underused part
On the platform that provides it, the list of domains an app contacted is more informative than the sensor log, and almost nobody looks at it.
A conversational app contacting a handful of domains is unremarkable: its own API, a content delivery network, a crash reporter, maybe a payment processor. Those are the components of an ordinary app.
A long list of unfamiliar domains is worth noticing. Advertising and data-broker infrastructure is recognisable once you have seen it, and a chat app with a dozen analytics destinations is making a choice about your data that is not described anywhere in its interface.
Domains are not contents. You are seeing where the app connected, not what it sent. This is the same limitation that runs through everything observable from a phone, and it is worth stating each time.
Cross-reference with the per-app data usage figure in your network settings. A large volume alongside a text-only interface is a discrepancy worth thinking about.
What the dashboard cannot show you
The gaps are as important as the contents, and each one is a place where people draw conclusions the log does not support.
It does not cover what you typed. Your messages are not a sensor access. The core of what an app receives is invisible here, by design, because it was never gated.
It does not cover clipboard reads consistently. Those surface as separate banners on some platforms; see what clipboard access means for what you paste.
It does not cover permissionless signals. Device model, time zone, locale, IP-derived location — none of these appear, because none of them require access to anything. That is the substance of location without the location permission.
It does not persist long. Both platforms keep a limited window, measured in days. There is no long-term history to audit.
It says nothing about retention or purpose. An access event has no annotation explaining why, and there is no mechanism by which it could.
What to actually do with it
A short recurring routine gets nearly all the value.
Enable the report if your platform requires it. Once a month, open it, look for background sensor access you cannot account for, revoke every permission an app holds and has not used, and skim the network destinations for anything that does not look like part of the app. That is the whole routine, and it applies to every app on the phone rather than only this category.
Then stop. The dashboard is a good instrument with a defined range. Beyond it, you are relying on published policies rather than on observation, and pretending otherwise — reading a domain list as proof of what was sent, or a clean sensor log as proof of privacy — is the one mistake this tool makes easy.