Building Panora: How Panora protects cloud-processed recordings

The last post said your recordings start on your phone, and that cloud processing is a choice. This one is about what protects a recording once you do choose cloud processing.

Encrypted before upload

When you choose cloud processing, Panora uploads encrypted audio chunks rather
than a plaintext whole recording. The backend receives encrypted data, not your
raw audio.

Processing is authorized and bounded

The backend validates a signed processing request for that recording, then
dispatches the work through the worker path. Worker access is bounded to
authorized processing jobs, and temporary worker audio files are cleaned up
after processing. Our backend is designed to store and move encrypted recording
data, and to process it only through that authorized cloud-processing path.

Backend artifacts are encrypted at rest

We also encrypt backend recording artifacts at rest, including stored transcript
and summary data. Recording keys are scoped to recordings and processing windows rather than relying on one always-on plaintext path.

Local mode stores nothing on Panora's servers

If you stay on the on-device path, none of the above applies, because none of it
happens: nothing about that recording is stored on Panora's servers. You hold a
copy on your phone; we hold none.

Why the backend holds anything at all

When you do use cloud processing, the backend keeps your encrypted recording
data so features can work across your library rather than one recording at a
time — and so the same foundation can support a web workspace, which a browser
(lacking your phone's keys) would need. That capability is something we are
building toward. Until then the rule stays simple: stay local and we store
nothing; choose cloud and what we hold is encrypted.