Mobile app privacy problems: permission creep, contact uploads and location exposure

Read each row as a lead, not a finding. Mobile privacy symptoms may originate in the app, an embedded library, the operating system, your account, or another connected service. A permission grant, battery spike, or contacted domain is a clue, not proof of collection.

Keep five claims distinct: allowed, accessed, transmitted, retained, and shared. Only the last four describe something that happened to your data. Record what you saw and when before changing settings or deleting anything; revoking device access does not remove copies already held on company servers.

Checking a capability that outlived its purpose

Permission creep is a mismatch between what an app can access and what its visible feature needs. An update may request contacts or location unrelated to that feature, while old grants can remain after a feature is removed; permission alone does not show that access was used.

Facebook's Android app is a known permission-creep case: it uploaded call and text history from devices that had granted the permission. Compare the feature, release, notice, prompt and system records for the specific app version before concluding that another grant was used.

A grant alone proves nothing about use. Deny or revoke unnecessary access, offer a manual or narrower alternative, remove the obsolete code path, and correct the notice. Recheck after every update, since a later release can restore permission access or alter the feature.

Activity that continues when the app is closed

Symptoms include location reminders, camera or microphone indicators, persistent services, battery drain, or mobile data use while the app is closed. These can point to unexplained background behavior, but none alone establishes that data was collected or transmitted. Record accompanying evidence before changing settings.

When the issue appears, record the time, app version, system indicator and dashboard reading, alongside battery and data use. Note whether a trip or call was active; these details let you compare the circumstances without treating power or network activity as proof.

Stop the active feature, revoke background permission, remove data or battery exceptions, and update the app. For unexplained sensor access, escalate through the FTC complaint process, your state attorney general, or a data protection authority if you are in the EU or UK, and contact device security support.

Address-book data crossing to a service

Contact uploads may be occurring when people who never installed the app receive invitations, your contacts appear as recommendations, or a deleted account returns after another address-book sync. The FTC's action against the Path app is a known contact-upload case, but those symptoms still require checking the actual data flow.

Distinguish on-device matching from a server upload. Review app settings, the account archive, invitation history, address-book access, and any hashing claim. On iOS, inspect Settings > Privacy & Security > Contacts; on Android, use Settings > Apps > [app] > Permissions. Those records can help locate the relevant control.

Turn off synchronization, revoke access, delete uploaded contacts through the account, and limit future matching. Use account deletion or contact-deletion controls; if neither is available, send a written request to the privacy contact in the policy, citing GDPR deletion rights or CCPA/CPRA. Tell affected people where context and policy require it.

Images that carry more than pixels

Photo exposure can mean a post reveals coordinates, a screenshot exposes a code, or an app retains full-library access for a one-photo task. Inspect both metadata and visible content before deciding what was exposed. A permission setting and the details in an already shared image are separate matters.

Inspect file metadata and visible content before blaming the app. Use ExifTool to read EXIF data, and establish whether the platform stripped coordinates, kept an original, or made a cloud copy. Those checks help distinguish details in the file from copies or versions held by the service.

Remove or replace the post, revoke broad library access, and switch to selected-photo access. Strip metadata from future exports with ExifTool or the platform share-sheet's location-removal option, then close shared links you no longer need. Check the available copies as well as the version you plan to share.

Tracing a place disclosure to its source

Location exposure occurs when a map, post, nearby feature or shared trip reveals a home; a photo or history can expose a routine or current movement.

Strava's global heat map is a known case: it revealed military base layouts. Treat the published or shared material as a separate exposure from the permission itself.

Identify the source before deleting anything: device permission, manually entered place, geotag, account history, family sharing, IP estimate, wearable, vehicle, or another person. If stalking or abuse is involved, preserve evidence first. Check each plausible source rather than assuming a device setting is responsible.

The FTC's guide to marketing a mobile app tells developers to honor privacy promises, get affirmative permission for material changes, and treat geolocation and persistent identifiers as child-privacy issues where COPPA applies. It supports accurate disclosure and change control, not a legal conclusion about any particular app.

Stop active sharing, change the audience, revoke location, delete retained history, and review connected devices. On iOS, revoke access in Settings > Privacy & Security > Location Services; on Android, use Settings > Apps > [app] > Permissions > Location. Make these changes after identifying the exposed source.

If a platform or host refuses removal, use its privacy or trust-and-safety complaint form, then escalate to the FTC, your state attorney general, or a data protection authority. Use safety planning or police support where there is an immediate threat.

Advertising IDs are only one key

Resetting an advertising identifier does not necessarily make profiles or recommendations disappear. Separate the platform advertising ID from account IDs, installation IDs, cookies, device tokens, IP addresses and purchase records. The reset changes one identifier, not every record associated with the account.

On iOS, App Tracking Transparency is in Settings > Privacy & Security > Tracking; on Android, the advertising ID reset path is Settings > Privacy > Ads. Check which identifier a control affects before treating a reset as deletion of account-level or server-side records, or of profile data.

Apply platform tracking controls, reset or delete identifiers the platform supports, and review account advertising settings. Use applicable opt-out or deletion routes under GDPR, CCPA/CPRA, or other law. State plainly what remains after those steps, since a reset does not itself establish that related account or server records are gone. See tracking methods compared for the different identifiers and techniques.

Reviewing app changes and testing fixes

NIST SP 800-163 on vetting mobile applications describes app security and privacy testing, permissions, vulnerabilities and authorized use in an organizational setting. Use it to structure a review after a permission or library change. It does not certify a consumer app or replace platform, legal, or store-specific analysis.

A repair is not complete until the exact feature has been tried again with a test account and minimal permissions. Recheck after the next app update, because updates can reintroduce access. Compare the before-and-after evidence rather than relying on the settings change alone.

Keep the before-and-after record, the owner, app version, and unresolved limits for later review. For deletion requests, retain the response and archive result; device permission changes do not establish that server-held copies have been removed. The record should distinguish local access from retained account data.

What observations can and cannot establish

An individual indicator seldom identifies collection, transfer, or retention by itself. Pair the signal with system records, app settings, account information, and network evidence where available; then make only the claim those records support. Several common observations therefore need a narrower interpretation.

Battery use: High battery use does not prove background tracking. Media, navigation, poor signal, updates, synchronization, and bugs can all consume power. Pair the battery reading with system and app evidence before drawing a conclusion, and note whether a trip or call was active when the issue appeared.

Revoked contacts: Revoking contacts access does not delete an address book already uploaded; it blocks future device access only. Use the app's account control to delete contacts it already holds, then ask for written confirmation. If there is no deletion control, send a request to the privacy contact.

Photo geotags: Removing geotags alone may not remove location exposure. Visible landmarks, text, timing, shared albums, and earlier copies can still reveal it. Check who saved or reshared the image before treating the cleaned file as the only copy or assuming the exposure has ended.

Advertising ID reset: Resetting an advertising ID does not erase an account profile. Account and server-side records may use other identifiers, so use separate controls for those records. The outcome depends on the controller, jurisdiction, and verification process.