Logo

Security & Privacy Whitepaper (Overview)Chapter 6

Chapter 6 Data Lifecycle & Deletion

This chapter defines the lifecycle of encrypted data (ciphertext chunks and manifests): creation, retention, expiration, and deletion. The goal is predictable behavior for users and auditors while maintaining zero-knowledge boundaries.

6.1 Data categories

  • Ciphertext chunks: encrypted file pieces stored in object storage.
  • Manifest: public parameters needed for download/assembly (no CEK).
  • State: authorization, progress, TTL, revocation flags, and minimal delivery evidence.

6.2 Deletion semantics

  • Sender-initiated deletion/revocation MUST make subsequent access fail (tokens invalidated / state denies access).
  • Deletion SHOULD trigger cleanup of related objects (chunks/manifest) where feasible.
  • System behavior MUST be consistent for recipients: revoked/expired transfers should show a clear reason.

6.3 Expiration policy & automated cleanup

6.3.1 Expiration triggers

  • Transfers SHOULD have an expiresAt policy (plan-based retention or user-selected TTL).
  • After expiration, access MUST be denied even if ciphertext still exists temporarily.

6.3.2 Automated cleanup

  • Background cleanup SHOULD delete expired chunks/manifests within a reasonable window.
  • Cleanup should be resilient to retries and partial failures (idempotent deletion).

6.3.3 UX constraints after expiration

  • Recipients MUST see an explicit "Expired" state and the next step (contact sender).
  • Senders SHOULD be able to distinguish "expired" vs "revoked" in management UI.

6.4 User-visible guarantees

  • Deletion/revocation MUST take effect for access control immediately (fail closed).
  • Physical deletion from storage MAY be eventual; however, access must remain denied without re-enablement.
  • Logs and evidence must remain minimal and must not include secrets (fragments/CEK).

6.5 Related Claim IDs