Browser Encryption and Recovery in Muninn
How encrypted journal content shapes search, recovery and the boundaries of a privacy promise.
Start with who can recover the keys
A journal can encrypt content before upload and still give the service a path to recover the keys. That distinction matters more than the location of the encryption call.
Muninn currently uses browser-side encryption with server-assisted recovery. An authenticated, email-confirmed browser can regain access, and the service can recover account keys. This makes recovery part of the product, but it also means the application does not provide end-to-end encryption against the service.
The earlier sample note at this URL described end-to-end encryption as a direction. This article describes the current implementation and its trust boundary.
Encryption changes the shape of the application
WebCrypto provides AES-256-GCM encryption for journal content and attachments. Entry revisions and attachments use fresh data keys. Current entry formats include encrypted titles, tags and categories, so these fields cannot simply become a conventional server-side search index.
Muninn instead builds an in-memory index from entries decrypted locally. Search queries stay in the browser, and the decrypted index is neither uploaded nor persisted as plaintext. Encrypted drafts and cached history live in IndexedDB.
The consequence is a more precise description of search: it works over locally available content. Offline access also depends on the keys and content already available in that browser. Encryption does not make every entry available on a device that has never downloaded it.
Describe the remaining visibility
Encrypted payloads do not mean the backend knows nothing. Some structural and wellbeing metadata remains visible to it. Recovery introduces another explicit trust relationship. These are separate properties and should be explained separately rather than collapsed into a single privacy badge.
The same care applies to optional AI. Users review selected content before consenting to external processing; controls exist at deployment, journal and request level. Production backend AI is disabled by default. Saving generated content through encryption paths does not undo the disclosure involved in processing that content externally.
A product promise that can be explained
For Muninn’s closed beta, the useful promise is specific: content is encrypted in the browser, local search stays local, and account recovery is service-assisted. It describes implemented behavior while leaving room to discuss its limits.
Recovery, search and external processing belong in the same design conversation. Each determines where information becomes readable and which party the user must trust.