Mobile operating systems were designed with a permission model that looks like security theater and occasionally is. The dialog appears, you tap Allow or Deny, and you move on. The problem is that permissions are not atomic — granting one capability often carries corollary access to data you didn't think about. And unlike a front door, permissions aren't always visible to you once granted: they work silently in the background, often forever.
The Contacts Permission: More Than an Address Book
Contacts access is among the most commonly granted and most underappreciated permissions. When an app requests contacts, you likely assume it wants to find your friends who also use the service. That's sometimes true. But the contacts database on your phone is one of the richest data sets you carry.
Your contacts list contains: names, phone numbers, email addresses, physical addresses, birthdays, notes, relationship labels, and photos. For many people, it contains business contacts with job titles and company affiliations, medical providers, financial advisers, and family members — people who never agreed to have their information uploaded to a third-party service.
When an app uploads your contacts for "friend discovery," it builds profile data on people who have never used that app — names, phone numbers, and relationship data associated with you. This is how "shadow profiles" are constructed. The GDPR has specific provisions around this, but enforcement is uneven.
Facebook's early growth strategy relied heavily on contacts harvesting. A user would install the app, grant contacts access, and Facebook would upload the entire address book — building association graphs of people who had never consented to any relationship with Facebook. This was later the subject of regulatory scrutiny in multiple jurisdictions, but the technical mechanism is widely used and largely unaddressed by platform permission models.
Location: Precise vs. Approximate, Foreground vs. Background
iOS and Android both now distinguish between foreground location (access while the app is in use) and background location (access at any time, including when the app is not open). They also distinguish between precise location and approximate location (a rough area rather than GPS coordinates).
The meaningful permission to audit is background location. An app that can read your GPS position whenever it wants — whether or not you've opened it — can reconstruct your daily movement patterns, infer your home and workplace addresses, identify who you spend time with (by correlating location with other users), and flag anomalies like unusual travel.
Apps that legitimately need background location: navigation apps, fitness trackers, some safety apps. Apps that commonly request it without a compelling reason: weather apps, shopping apps, games, and ad-supported utilities. The pattern to watch for is an app requesting background location where the core feature could be accomplished with foreground-only access.
| Permission | What It Exposes | Legitimate Use Cases |
|---|---|---|
| Contacts | Your entire social graph, including people who didn't consent | Messaging apps, phone apps, address book sync |
| Background Location | Movement patterns, home/work addresses, social associations | Navigation, fitness, some safety apps |
| Microphone | Audio in your environment when the app is active | Voice calls, recording apps, voice assistants |
| Camera | Visual capture; some apps can silently capture frames | Photo apps, video calls, document scanning |
| Storage / Files | Read access to all files (broad on Android pre-scoped storage) | File managers, document editors, media players |
| Clipboard | Content of the clipboard — passwords, tokens, copied text | Password managers, translation apps |
The Clipboard and Notification Access: Underrated Risks
iOS 14 introduced a banner notification whenever an app reads from the clipboard — and users discovered that a surprising number of apps were silently reading clipboard contents every time they were opened. TikTok received significant coverage for this behavior in 2020. The clipboard is a particularly sensitive data source because users routinely copy passwords, one-time codes, authentication tokens, and account numbers.
Notification access — granted to apps that want to read your notifications — provides access to every notification you receive, from every app, including text message previews, two-factor authentication codes, and email subject lines. On Android, apps with notification access can read the full body of incoming notifications. This permission is rarely needed by legitimate apps outside of specific use cases (smart watches, notification management apps), but it's worth auditing in your settings.
How Ad SDKs Aggregate Across Apps
Many free apps monetize through advertising, which means they embed advertising SDKs from companies like Google AdMob, Meta Audience Network, or dozens of smaller ad networks. Each SDK may collect data independently — including the advertising identifier (IDFA on iOS, GAID on Android), device model, OS version, app usage timing, and any permissions the host app has granted.
The advertising identifier is designed to be a privacy-preserving alternative to device fingerprinting: it's a resettable identifier that doesn't directly tie to your identity. In practice, resetting it rarely matters because ad networks can re-identify devices through fingerprinting techniques — combinations of device characteristics that together uniquely identify a device even without a persistent identifier.
The aggregation problem is that a single SDK embedded across thousands of apps can correlate your behavior across all of them simultaneously, building a cross-app behavioral profile that no single app has individually. This is the metadata surveillance problem applied to app usage — individual data points seem innocuous; the aggregate is detailed and persistent.
How to Actually Audit Your Permissions
Both iOS and Android have improved their permission auditing interfaces significantly over the past few years.
On iOS (Settings → Privacy & Security)
Navigate to each sensitive category (Location Services, Contacts, Microphone, Camera, etc.) to see every app that has requested that permission and what level of access it currently has. The "App Privacy Report" in iOS 15+ shows which apps have recently accessed hardware and network resources.
On Android (Settings → Privacy → Permission Manager)
Navigate by permission type to see which apps have each access level. Android 12+ also introduced a privacy dashboard showing a timeline of recent permission accesses — useful for identifying apps that use permissions unexpectedly.
The question to ask for each app/permission combination: "Does this app need this access to provide the feature I'm actually using it for?" A flashlight app requesting microphone access has no legitimate reason. Revoke it.
The Principle of Least Privilege in Practice
The security principle of least privilege — grant only the access required for the task at hand — applies directly here. Most apps work fine with reduced permissions. A camera app doesn't need your contacts. A recipe app doesn't need your location. A messaging app doesn't need access to your photos unless you're actually sending photos.
The most aggressive privacy posture: revoke all permissions by default, then re-grant them temporarily when a feature actually needs them. iOS makes this relatively easy with "Ask Next Time" location access. Android has a similar mechanism. Neither is perfect, but they force a deliberate grant rather than a permanent one.
Haven requests only the permissions it needs: camera and microphone for video/voice calls when those features are used, contacts for finding other Haven users (with on-device matching rather than server-side upload), and storage for file attachments. We don't request background location, because we have no feature that requires it.