Observing sharing-link revocation without assuming immediate consistency

Goal

Give a sharing-link revocation claim a concrete test oracle and observation window. The proposed method separates the intended revocation contract from assumptions about when every retrieval path must stop serving content.

Prerequisites

Use a disposable application, an inert shared document, and the product’s supported anonymous or guest access path. Record the documented revocation semantics and an operator-approved observation budget before testing.

Steps

1. Create a sharing link and confirm that it grants exactly the intended access to the synthetic document. Record a fixture label rather than the reusable link value in routine reports.

2. Revoke the link through its owner’s supported interface. Record the revocation acknowledgment and distinguish it from any explicit signal that propagation has completed.

3. Retrieve the document through each supported sharing path within the agreed observation budget. Compare actual content availability with the product’s stated immediate or eventual revocation contract.

4. Create a fresh permitted link as a control after revocation. This helps distinguish successful revocation from a general outage or a broken guest-access fixture.

5. If behavior violates the declared contract, preserve the smallest timing and path evidence needed to reproduce it. Rerun the same bounded observation after the relevant fix.

Expected result

The report should state which path served which synthetic content after which revocation event, together with the contract used to judge that observation.

Limits and test basis

This proposal reports no measured propagation time and defines no universal delay threshold. Copies already downloaded by recipients and external caches outside the product’s control are separate retention questions. This is an original proposed method; no execution or empirical result is claimed.