Security

Encryption at rest

Files are encrypted on the server with AES-256-GCM before they are stored. Each file gets its own random 256-bit data key. The file body is encrypted with that data key. The data key is then wrapped with a server master key and stored as a versioned value. Passwords are encrypted on the server with AES-256-GCM under the same master key, also versioned. The master key lives with the application server. It is not stored in the database and it is not sent to the browser.

This is not a zero-knowledge service and not client-side encryption. The application can decrypt content when it serves a download or shows a password. Anyone who obtains the master key and the stored ciphertext can decrypt as well. That includes operators of Poietes LLC who can access the server secret and the database or private storage.

Access control

Database tables use row-level security so a signed-in user reads their own rows. File bytes sit in a private storage bucket. Object paths are scoped to the owner's account id. List responses omit key material and storage paths. A beneficiary sees shared file metadata only after a single-use invite is accepted, which records an access grant. Invite tokens are stored as hashes.

What is not built

Check-in email and automatic release of a vault are coming soon. The settings screen saves a check-in interval, a release delay, and a beneficiary. No scheduled job reads those values, sends mail, or grants access.

Transport and headers

The hosting configuration attached to the app sends HTTPS strict-transport headers, a content security policy, and headers that block framing and content-type sniffing. Those headers apply on the hosted site.

Contact

Report a security issue to Poietes LLC at [email protected].