Logical Files protection contracts

Campus Files is byte-agnostic storage. Every new logical file nevertheless declares one immutable protection contract so callers, trusted services, and higher-level products cannot silently confuse plaintext, endpoint ciphertext, and workload ciphertext. The contract is metadata and policy; Files does not hold encryption keys and does not pretend it can prove that arbitrary bytes are valid ciphertext.

Protection modes

Files mode	Key Protection Foundation class	Who may receive plaintext	Intended use
client-sealed	session or ephemeral	An authorized browser/native endpoint	Drive/Content objects, Photos media, Drop ciphertext, frontend-private exports
installation-sealed	installation	The exact Runtime installation named by CampusOS	Workload snapshots, encrypted imports/exports, app artifacts that only one Firecracker installation opens
platform-readable	no encryption-key claim; exact service and purpose are mandatory	The named Campus/app service after ordinary owner/ACL authorization	Integration data that ClickHouse, indexing, conversion, or another declared service must read

client-sealed is rooted in the Session Keyset when data must survive login/device changes. It may also name ephemeral authority for a one-transfer protocol such as Drop. The logical file never contains a Session keyring handle: Content or the frontend crypto broker owns the envelope and the endpoint uploads only ciphertext.

installation-sealed is separate from the account keyring. CampusOS derives the recipient identity from the authenticated app backend's installation and records it; callers cannot choose another installation. The Runtime-owned private recipient remains inside that installation's security boundary. Browser frontends cannot create installation-sealed records directly.

platform-readable requires both service and purpose. Those fields do not grant access: file ownership, ACLs, installation permissions, and the calling route must still authorize the transfer. They prevent a future privileged Campus service from treating generic plaintext as available for an unrelated purpose. An app may name only its own app ID as the service.

API shape

Creation always includes protection:

{
  "name": ".encrypted/asset.campus",
  "contentType": "application/vnd.campus.encrypted-content",
  "size": 1234,
  "sha256": "...",
  "protection": {"mode": "client-sealed", "keyClass": "session"}
}

Other valid shapes are:

{"mode": "installation-sealed"}
{"mode": "platform-readable", "service": "analytics-app", "purpose": "clickhouse-import"}

The server expands installation protection with keyClass: "installation" and the authenticated recipientId. SDK creation methods require an explicit protection choice. A rewrite may repeat the same normalized value but cannot change it; conversion creates a new logical file, verifies the new representation, switches the higher-level reference, and only then retires the old file.

Records created before this contract are returned as legacy-unclassified. They remain readable under their existing owner/ACL policy for migration, but Content refuses to admit them as encrypted object versions. Campus never silently upgrades them to platform-readable or client-sealed.

Product layering

The supported media path remains:

Files (`client-sealed` bytes)
  -> Content / Campus Drive E2E foundation (Session-rooted envelopes and sharing)
       -> Drive app
       -> Photos / Gallery app

Photos references the same Content objects as Drive. It does not create a second vault, request raw Files authority, or label plaintext thumbnails as encrypted originals. Derivatives are separate Content objects or explicitly platform-readable cache files with a named producer/purpose.

Checkpoints and Firecracker

Files protection and Firecracker checkpoint encryption solve different problems. Checkpoint encryption protects persisted VM state after capture. It does not make arbitrary bytes inside a running VM trustworthy, prevent an authorized workload from ingesting malicious data, or turn a platform-readable ClickHouse dataset into user E2E data. Workloads still need input validation, least-privilege Files/S3 capabilities, and isolated restore/verification before a checkpoint becomes trusted state.