Revoking access cannot recall copies already taken

What it is

After someone is taken off a list or a link, they cannot open the live copy in the product. That is revoking access. The PDF on their disk, the attachment they forwarded, the screenshot, the paragraph in their notes, the product cannot touch. Cannot recall has to be said at revoke time, or “sharing stopped” is heard as “that content vanished from the world.” This is the consequence of the revoke act, not the current-scope badge, and not the widening confirm.

Why it happens

Online permission gates the next open. Download, copy, and screenshot happen after open; the object has left the permission system. People analogize from folders: kicking someone from a share drive, while the offline pack on their laptop remains. If revoke feedback only says “Jia removed,” Jia’s local file, chat attachment, and mail attachment all remain, and people plan the next step as if recall succeeded (tell a client the file is void, or tick a compliance box). The copy draws the control boundary: the product can stop account access; it cannot stop bits that already left. If the view rung allows download, the hole is larger. Disabling download shrinks it; it does not kill memory or a second photograph. Turning a link off likewise does not delete saved files.

Studying it

Have someone share, confirm the other party downloaded, then revoke, and ask whether the other party can still get that content. Compare: feedback that only says removed, versus feedback that online access has stopped and local copies are untouched.

Independent variables: whether revoke copy splits live access from copies already taken, whether the limit was previewed at invite time. Dependent variables: belief that the file vanished from the other device, whether remedies after revoke (change the content, change a password, legal notice) match the real risk.

If the lab never actually downloaded, people hear the question as “can they open the link.” The download has to happen. Do not measure ordinary revoke as if it were an encrypted document that expires itself.

Where it stops holding

Streaming view with download and cache blocked makes a high-quality leftover hard; copy can say “live viewing will stop” and still must not promise “nothing was ever kept.” End-to-end local packs were never under the server; revoke can only stop key refresh, and must say so more strongly. A reprint already on a third-party platform is untouched by revoking the original; point at that platform’s delete flow instead of a fake network-wide recall. Org DLP or device management can wipe corporate devices; only those devices may be written into “can recall.” Personal devices still cannot.

Applying it

• Revoke confirm uses two sentences: “Jia will no longer open the live version.” “Copies already downloaded, forwarded, or duplicated will not be deleted.”
• Preview the same limit at the first share that allows download or copy; do not wait until revoke.
• For sensitive objects, default download off and limit ordinary copy on the view surface; still admit screenshots exist.
• Verify: after the other party has saved a file, revoke, and ask the sharer whether the other party can still get it. “No” while they still can is a copy failure. Check whether the next step they take matches “the copy remains.”

Related

• Within the group: H8.08.1 Current sharing scope must sit beside the content · H8.08.2 Widening access needs an explicit confirm · H8.08.3 Permission inheritance must be understandable · H8.08.4 View, comment, and edit roles follow least privilege · H8.08.5 Link sharing spreads farther than named people · H8.08.7 Org defaults vs personal share need a stated winner
• Adjacent: H8.04 Copy, Share, and Export · H6.14 Account Deletion and Data Erasure
• Search terms: revoke access · downloaded copy · cannot recall