The Veil

"The most sensitive data in the family should be unreadable the moment it leaves the machine that made it — even on the way into a backup."

Line-Level Encryption at Rest

Forge holds medical records, so the ground-truth log is encrypted at rest. The mechanism is the veil: each JSONL line is Fernet-encrypted, base64-wrapped, keyed by a passphrase in the office Keychain (its own slot, separate from the rest of the family). The encryption is per line, not per file — every op-log event is an independently sealed record. Health data earns this on its way into the CCC and NAS backup path: a backup of the log is a stream of opaque blobs, readable only where the passphrase lives.

Graceful, Family-Wide

The veil policy is deliberately graceful across the fleet rather than fail-fast. The office machine holds the key, so its journal stays encrypted in practice. A Mac without the passphrase does not crash or refuse to run — it warns at boot and writes plain. This matters because the log travels: peers that receive it via backup can round-trip the encrypted blobs without ever being able to read them, and a keyless machine degrades to a warning instead of a hard stop. The earlier design had a fail-fast startup gate; it was retired in favor of this softer, family-wide posture.

The veil is line-level Fernet, keyed by the office Keychain; the policy is graceful, family-wide. Health data is encrypted at rest on its way into backups, office holds the key and stays readable, and a keyless machine warns and writes plain rather than failing hard. Every line is sealed on its own.

What the Veil Does and Does Not Cover

Be precise about scope. The veil encrypts the JSONL op-log lines. Uploaded binaries — the check-up PDFs, the prescription photos — live plain on disk under the office-only, FileVault-covered posture, the same as cwkPippa's uploads. The veil is not a substitute for the office-only rule from the next lesson; it is the at-rest layer underneath it. Defense here is in pairs: office-only keeps the data on one trusted machine, and the veil makes the log unreadable if a copy of it ever travels beyond that machine's live memory.

Code

A sealed op-log line, and the graceful degrade·text

# On office (key present) - each line sealed independently:
gAAAAABm...base64-fernet-blob...   # crumb.add, encrypted
gAAAAABm...base64-fernet-blob...   # interpretation.add, encrypted
gAAAAABm...base64-fernet-blob...   # artifact.add, encrypted
#   a backup of this file is a stream of opaque blobs.

# On a keyless Mac (receives the log via backup):
#   - can store and round-trip the blobs (never decrypts them)
#   - if it WRITES, it warns at boot and writes plain
#   - it never crashes or refuses to run  (graceful policy)

# key slot: office Keychain (cwkforge veil), separate from siblings

Exercise

Why encrypt the log at the line level rather than encrypting the whole file once? Think about what has to happen every time a single new crumb is written, and what a backup process needs to do with the file. What does per-line sealing buy that whole-file encryption would make awkward?

Hint

Append-only writing wants to add one sealed line without re-encrypting the whole file, and a backup wants to copy the file as-is. Per-line Fernet makes each append self-contained and the whole file safe to ship untouched.

Line-Level Encryption at Rest

Graceful, Family-Wide

What the Veil Does and Does Not Cover

Code

External links

Exercise

Progress

Comments 0