Revocation and retention
Cutting off access in seconds, link expiry, and when every copy of a file is deleted.
The company stays in control of a file after it is sent. Every transfer and upload request expires, can be revoked at any moment, and has its data deleted on a fixed schedule from every copy, the disaster-recovery region and backups included.
Revoking a link
A member revokes their own transfers and upload requests. A tenant admin can revoke any transfer or upload request in the tenant (UC-3, FR-20). From that moment:
- No new download or upload can start.
- Recipients who open the link see that it was revoked.
- For an upload request, further uploads stop. Files already received stay with the member until their retention ends.
How fast it takes effect
| Effect | Design target (NFR-6) |
|---|---|
| No new download or upload can start | Within 5 seconds of the revocation |
| A download already in progress stops | Within 60 seconds of the revocation |
| Upload parts sent after the revocation | Never assembled into a file |
Downloads stream through the service under a grant bound to the recipient's verified session; there is no pre-signed URL that could outlive a revocation. Revoking closes the transfer's sessions in the same database transaction, so new requests fail at once. A running stream re-checks the transfer every 30 seconds, so it stops within 60.
An upload only becomes a file through a server-side completion call that re-checks the transfer under a row lock. Parts sent after a revocation are never assembled, and reconciliation removes them.
A revocation survives a regional failover
The revocation commits first, so it takes effect immediately. The API then writes its record to the audit archive in both regions, Tokyo and Osaka, before it confirms. If that archive write fails, the API answers with a 503 that means "revoked, not yet confirmed", never "failed": the revocation stands, and a retry completes the record. The failover and restore runbooks re-apply every confirmed revocation before any worker starts, so a failover doesn't bring a revoked link back. The disaster-recovery gaps still open are tracked in issue #42.
Expiry
| Setting | Rule |
|---|---|
| Expiry range | 1 hour to 30 days, for transfers and upload requests alike (FR-3, FR-10) |
| Default | 7 days, or the tenant's maximum if that is shorter |
| Tenant maximum | Set by a tenant admin as the longest allowed expiry (FR-23) |
| Extending | A member can extend an active transfer's expiry, within tenant policy (FR-9) |
Every request compares the link's expiry with the current time, so a link stops working the moment it expires. A lifecycle job then records the expiry and schedules deletion.
Files received through an upload request follow their own clock. They are kept for the tenant's retention period, counted from each file's upload: 30 days by default, configurable from 1 to 90 days. The request expiring or being revoked doesn't shorten it, and the member can delete received files earlier (FR-13).
Data lifecycle
The PRD's lifecycle table is the single source for when data is deleted.
| Data | Deletion is triggered when |
|---|---|
| Files of a transfer, quarantined ones included | The transfer expires or is revoked |
| Files removed from a held transfer, or of a cancelled transfer | The file is removed, or the transfer is cancelled by the member or after 7 days as an unsent draft |
| Files received through an upload request | Their retention period ends, or the member deletes them |
| Parts of an upload that never completed | 24 hours after the last part arrived, or when the transfer or request is revoked |
| Stored objects no transfer or request refers to | 24 hours after they appear, found by the reconciliation job |
| Metadata of transfers and upload requests | When no audit record refers to it any more, at most 365 days after the item's last event |
| DLP findings (detectors and counts) and decisions | With the metadata of their transfer or upload request |
| DLP location hints and masked previews | When the file's contents are deleted |
| Recipient domains a tenant has sent to | 365 days after the tenant last sent to the domain |
| Audit records | 365 days after they were written |
| Verification codes and sessions | When they expire |
| Application, load balancer, CDN and WAF logs | 90 days after they were written |
Metadata is kept as long as an audit record points to it, so the audit trail stays readable for its full year even after the files are gone.
Deletion from every copy
A file's contents are deleted from every copy, in the primary region, the disaster-recovery region and backups, within 7 days of its deletion trigger (NFR-8).
- One workload deletes. Only the lifecycle jobs may delete objects. They remove every version of each object in Tokyo, then every version of its Osaka replica. Both regions are deleted explicitly because S3 replication doesn't copy deletes of specific versions.
- Daily reconciliation. A job lists storage in both regions, compares it with the metadata, reports leftovers, deletes orphaned objects older than 24 hours, and aborts unfinished uploads with no new part for 24 hours.
- Safety nets. Lifecycle rules on every files bucket expire old object versions and abort unfinished uploads after 7 days, behind the job.
- Database records leave the live database at the trigger and age out of database backups within the 14-day restore window.
Deleted contents can't be recovered, by design. If the database is restored to an earlier point, metadata that refers to deleted files is marked deleted rather than shown as a broken link (NFR-11).
Audit retention
Audit records are kept for 365 days and then deleted (NFR-9). In production, archived records sit under S3 Object Lock, so nobody can change or delete them before their retention ends. See Audit log for what is recorded and how it is protected.
Source: PRD, Architecture, Data model