Revocation has to clean up data already taken

What it is

Turning a permission off only stops future access. If a copy of contacts, already-uploaded photos, or cached precise coordinates still sits on a server or in a local database, revocation is incomplete in effect. After a revoke, data that permission opened has to be cleaned up or isolated, and people need to see whether cleanup finished. This entry is about the fate of data already taken. It is not about whether the app has a jump to Settings.

Why it happens

A grant is implemented as "read once, write into our store." The system toggle governs API calls, not the copy the app already made. People's model is "shut the tap, the water should be gone"; if friend lists, face albums, or traces remain, the switch feels broken. Cleanup has to count derived objects: "people you may know" from contacts, location tags extracted from photos. Removing the UI entry without deleting backend objects is another case of "gone from the screen" not meaning deleted.

Studying it

During the grant, plant an identifiable trace (a tagged contact, a photo with a unique filename). After revoke, inspect client storage, backups, and the app server.

Independent variables: whether revoke fires a deletion request, whether deletion includes derived profiles, whether the person must confirm irreversibility. Dependent variables: whether the trace is still readable via API, whether the UI still shows it, whether users' belief that "it's gone" matches reality.

Do not inspect only the local cache. Sync queues, analytics pipes, and recommender copies are the usual leftovers. A lab that only looks at the next screen after revoke will misread an empty list as gone data.

Where it stops holding

Legal or security retention (an address on an invoice, a device fingerprint needed for fraud checks) can refuse instant erasure, but the revoke flow has to say what stays, for how long, and why. Jointly owned content (a shared album others still use) cannot be unilaterally destroyed because one person revoked a permission. If a one-time grant never sent data off the device, cleanup is local cache, not the server.

Applying it

• For each permission, list data objects that could be written while it was on. On revoke, delete or detach identifiers along that list, including derived tables.
• In the post-revoke state, say what this app has already dropped, what billing or law still keeps, and when leftover deletion should finish.
• After revoke, do not keep showing contacts or library content the app is no longer allowed to refresh, even if a cache waiting to be deleted still exists locally.
• Verify by writing a searchable marker while granted, revoking, waiting for sync, then signing in on a new device and querying the server. If the marker remains, cleanup failed. Then ask whether the person thinks the data is still there—if belief and fact diverge, the notice failed too.

Related

• Within the group: H4.04.1 The app needs an in-app permission status and a jump to Settings · H4.04.3 Asking again needs a fresh user action
• Adjacent: O1.07 Right to Erasure and Data Deletion · O1.10 Consent Granularity and Withdrawal · O2.10 Privacy Dashboards and Data Visibility
• Search terms: revocation erasure · post-revoke cleanup · right to erasure