{ "schema": "org-writing@v1", "slug": "the-revocation-window", "kg": { "id": "org:writing:the-revocation-window", "type": "brick", "graph": "/kg.json" }, "title": "The revocation window", "subtitle": "Every system that lets people work offline holds a period in which revoked material is still readable on a device, and the honest ones say so", "abstract": "Why revoking access is a message that has to arrive rather than a state that changes, and what naming the gap costs against what hiding it costs. The canonical treatment of the revocation window.", "kind": "brick", "topics": [ "Privacy" ], "courseMemberships": [ { "course": "org:courses:privacy", "topic": "Privacy", "wall": "org:walls:engineering", "position": 4, "total": 6 } ], "publishedAt": "2026-08-03T00:00:00.000Z", "version": 1, "guidelinesVersion": 15, "brief": { "problem": { "text": "Revoking access reads to a person as an event that has already happened everywhere, while the product knows it is a request that may not arrive, may not succeed, and will not report back when it fails.", "claims": [ "recipients might see the message before it is deleted" ] }, "mechanism": { "text": "Revocation is an instruction that has to travel to each device already holding a copy, so the material stays readable for exactly as long as the instruction takes to arrive, and nothing bounds that duration on a device that never reconnects.", "claims": [ "cannot be removed by any server action" ] }, "move": { "text": "State the window in the interface where the revoking happens, with its ordinary duration and its unbounded case, and offer the one setting that closes it by keeping the material off devices entirely.", "claims": [] } }, "sources": [ { "repo": "mnstry-monorepo", "path": "docs/10-platform/50-database/65-sync/privacy-revocation.md" } ], "canonicalPath": "/writing/the-revocation-window/", "body": "You take back access to something, and the interface says it is done. What the interface means is that a row changed on a server. What you heard is that the material is gone from wherever it went, which is a different sentence entirely, and the distance between the two is where most of the discomfort in modern privacy lives.\n\nWhatsApp documents its own version of that distance more plainly than most, which is worth knowing because it removes the excuse that ordinary people cannot hold the idea. A sender has about an hour to request that a message be deleted for everyone. Recipients might see the message before it is deleted, or if the deletion was not successful. The sender is not told when it fails. Both parties need current versions of the app for the request to be honored at all, and on the iOS app a recipient may still hold media in their Photos library after the message itself has left the chat. Every one of those sentences is on the company's own help pages rather than in a researcher's write-up, and together they describe a revocation that is a best effort rather than an event.\n\nThe reason is structural and it survives every implementation. A copy already resting on a device that is not connected cannot be removed by any server action, so the mechanism is simply that revocation is an instruction which has to travel to each holder of a copy, and the material stays readable for as long as the instruction takes to arrive, which is nothing at all when the device is awake and unbounded when the device is a phone in a drawer. Cached email behaves this way. So does a file-sync folder, an offline document cache, and every messaging product that has ever offered to unsend. Naming this is not a confession about a particular product. It is a description of what synchronizing means.\n\nWhat varies between products is not whether they carry the window, since they all do, but whether the person on the wrong side of it is told. Our own sync design notes hold the line we would want held against us, that we do not claim to eliminate the window, and they name the one setting that actually closes it, which is refusing to let the material reach devices in the first place and paying for that in offline access. Those notes describe a dormant capability rather than a shipping one, and the argument is what we are standing behind here, not an implementation anybody can go and use. The engineering may or may not return. The sentence holds regardless, because the honesty in it costs a paragraph and is available to any team today.\n\nWhat that paragraph buys is a person who can act. Told that revocation is instant, someone who has just cut off access to something sensitive believes the matter is closed and stops thinking about it. Told the truth, which is that it usually resolves in seconds, that it can last as long as a device stays dark, and that they will not be notified either way, that same person makes different and better choices about what to send, to whom, and under what setting. The window has never been the failure. Every system that lets people work on a train has one, and the ones worth trusting are the ones that hand you its shape before you need it rather than after you have found it out for yourself.", "apparatus": { "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.", "references": [ { "id": "org:references:the-revocation-window:r01", "author": "WhatsApp", "work": "How to delete messages, WhatsApp Help Center", "year": 2026, "relevance": "The case anchor, chosen because it is a vendor stating its own window in its own consumer help pages at very large scale. It supplies the time bound, the failure silence, the version dependency, and the media-library residue, which together describe a revocation that is a best effort rather than an event." }, { "id": "org:references:the-revocation-window:r02", "author": "MNSTRY platform documentation", "work": "Privacy window and revocation handling", "year": 2026, "relevance": "The internal source. A dormant reactivation specification carrying the sentence the brick holds us to, that we do not claim to eliminate the window, plus the one mitigation that actually closes it by keeping material off devices. The capability it describes is mothballed and the brick claims no implementation." } ], "claims": [ { "id": "org:claims:the-revocation-window:c01", "claim": "WhatsApp's help documentation states that a sender has about an hour after sending to request deletion for everyone.", "basis": "The vendor's own help center, verified externally at authoring time.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c02", "claim": "WhatsApp's help documentation states that recipients might see the message before it is deleted, or if deletion was not successful, and that the sender is not notified when deletion for everyone was unsuccessful.", "basis": "The vendor's own help center.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c03", "claim": "WhatsApp's help documentation states that successful deletion for everyone requires the sender and the recipients to be using the latest version of the app, and that recipients on its iOS app may still hold sent media in their Photos library after the message leaves the chat.", "basis": "The vendor's own help center.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c04", "claim": "A copy already resting on a device that is not connected cannot be removed by any server action, which makes the revocation window inherent to offline-first and synchronizing systems rather than a defect of any particular one.", "basis": "Deductive. Removal of a local copy requires an instruction to reach the device; an unreachable device receives no instruction. The internal source states the same conclusion and lists cached email, file sync, and offline document caches as instances.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c05", "claim": "Our own sync design notes state that we do not claim to eliminate the revocation window, and identify keeping sensitive material off devices entirely as the mitigation that closes it at the cost of offline access.", "basis": "The internal document's mitigation layers, which name the online-only path as the zero-window option.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c06", "claim": "The internal document is a dormant reactivation specification, and the offline capability whose window it analyses is not a shipping capability.", "basis": "The 2026-07-11 operator ruling carried at the head of the document, which states that the launch profile has no active offline cache or sync-revocation claim.", "confidence": "verified", "sources": [] }, { "id": "org:claims:the-revocation-window:c07", "claim": "Products that carry a revocation window and publish its shape are a minority of the products that carry one.", "basis": "An impression formed from reading consumer help documentation across messaging, mail, and file-sync categories at authoring time. No survey, sample frame, or count stands behind it, which is why the brick states it as an observation about variation rather than as a proportion.", "confidence": "directional", "sources": [] } ], "concepts": [ { "id": "org:concepts:revocation-window", "name": "The revocation window", "definition": "The interval between access being revoked on a server and the revoked material ceasing to be readable on every device already holding a copy. Ordinarily seconds when the devices are connected, and unbounded for a device that never reconnects, because a copy already resting on an unreachable device cannot be removed by any server action. The window is inherent to every offline-first and synchronizing system, including cached mail, file sync folders, offline document caches, and every product that offers to unsend, which makes naming it rather than eliminating it the available honesty. The one setting that closes it is refusing to let the material reach devices at all, paid for in offline access.", "provenance": "canonical" } ], "researchContext": "Harvested from one internal document, dormant under the 2026-07-11 mothball\nruling. The argument survives the ruling and the implementation claims do\nnot, which the brick states in the body rather than burying here, since a\nreader who takes away that we ship a revocation mitigation would have taken\naway the wrong thing.\n\nWhatsApp replaced the anchor originally reached for. Signal's delete for\neveryone is the more familiar example in privacy writing, but its own\nsupport page could not be retrieved at authoring time, and the readily\navailable descriptions were community wiki rather than vendor text. The\nbrick's argument depends on the vendor saying it, not on the fact being\ntrue, so the anchor moved to the vendor whose statement could be verified.\n\nThe operator instruction for this brick carried the phrase that almost\nnobody says so. Authoring found the opposite in the one case examined\nclosely, since WhatsApp does say so, and the body was written to that\nfinding instead: the window is universal, the disclosure varies, and the\nvariation is the whole subject. The counting claim is retained above and\ngraded directional so a later audit can find it and either measure it or\nretire it.\n\nBoundary with what-your-claim-excludes, kept on purpose: that brick cites\nthe same internal sentence as an instance of publishing a limit, and argues\nabout disclosure. This one argues about the window itself, what causes it,\nand why no implementation removes it. Neither piece needs the other's\nconclusion." }, "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json", "releaseHash": "746a48a47bc7ddd47bbab2a2a25e0919913430b0728dce061f2ee464abb75452", "versions": [ { "version": 1, "cutAt": "2026-08-03", "note": "Initial publication, privacy wave", "visibility": "published", "path": "/writing/the-revocation-window/", "contentHash": "sha256:cade4c51444bc05a", "releaseHash": "746a48a47bc7ddd47bbab2a2a25e0919913430b0728dce061f2ee464abb75452" } ] }