🔐 Designer-friendly security map

SunOS End-to-End Encryption Flow

The user experience can feel simple — “Use Face ID or Touch ID to open my workspace” — while the system keeps the actual document encryption keys separate from login.

Identity / passkey Encryption keys Encrypted data Browser-only plaintext Risk area

The simple version

A passkey proves who the user is. A separate workspace key decrypts the content. Your server stores encrypted data, not readable documents.

Important distinction
Passkey ≠ document key.
The passkey unlocks access. The workspace key unlocks the actual notes, pages, tables, and files.

What the user sees

“Unlock with Face ID / Touch ID.” After that, the workspace opens normally. The cryptography stays invisible unless something goes wrong.

UX goal
Make the encrypted mode feel like opening a locked notebook, not operating a security console.

Setup flow: creating the encrypted workspace

This happens once when the user enables end-to-end encryption for a workspace.

User Face ID / Touch ID Browser Generates a random workspace key Plaintext exists locally only Server Stores encrypted data and wrapped keys Cannot read content Recovery Key User saves it Workspace Key Encrypts documents Wrapped Key Safe to store remotely Create / verify passkey Generate key Wrap / encrypt key Store only encrypted Fallback unlock
User enables encryption.The app creates a new encrypted workspace.
Browser creates a workspace key.This is the real key that encrypts pages, blocks, files, titles, and comments.
The workspace key is wrapped.“Wrapped” means the key itself is encrypted so it can be safely stored or synced.
Server stores ciphertext only.The backend receives encrypted content and encrypted keys, not readable documents.
User saves a recovery key.This protects against lost devices, failed passkey sync, or account recovery issues.

Daily unlock flow: opening the workspace

This is what happens after setup. To the user, it feels like one biometric unlock.

User Unlocks with Face ID / Touch ID Passkey Proves identity without exposing the private key Server Sends encrypted workspace data + wrapped key Browser Unwraps key and decrypts locally Workspace Key In memory while open Readable UI Plaintext appears User gesture Verified login Encrypted payload Unwrap key Decrypt locally
Plain-language promise
The server can help the user sign in and sync encrypted data, but it should not have the raw key needed to read the workspace content.

Where each piece lives

Piece What it does Where it should live Readable by company?
Passkey
User identity proof 		Confirms the user is allowed to access the account. Protected by the device / platform. The private key is not given to your app. No private key access.
Workspace key
Actual content key 		Decrypts pages, docs, files, tables, and comments. Generated in the browser. Kept in memory while unlocked. No, if never sent or stored raw.
Wrapped key
Encrypted copy of the key 		Lets the user sync or recover access without exposing the raw key. Server or browser storage. No, unless the wrapping method is compromised.
Encrypted content
Ciphertext 		The notes and files after encryption. Server, browser cache, backups, databases. No, not without the workspace key.
Plaintext content
Readable workspace 		What the user sees after unlock. Browser memory and UI while the workspace is open. Should not be available to backend systems.

Strengths

Company cannot casually read user work.
The server stores encrypted content, not readable pages.
Database leaks are less catastrophic.
Attackers who steal backend data mostly get ciphertext and wrapped keys.
Great user experience.
Face ID and Touch ID can make strong security feel effortless.
Clear trust story.
“We do not have your raw content key” is a strong privacy position.

Weaknesses and inherent risks

XSS can break the model while the workspace is open.
If malicious JavaScript runs inside your app, it may read decrypted content, call decrypt functions, or exfiltrate the in-memory key.
Internal engineering can still ship harmful code.
Because the web app is delivered by your company, a malicious or compromised deployment could alter the auth flow, capture plaintext after unlock, or weaken encryption logic.
Browser extensions and compromised devices are hard to defend against.
If the user’s device is compromised, the app may not be able to protect readable content on screen.
These risks are inherent to web-based E2EE.
They cannot be completely eliminated in a browser app because the browser must eventually receive code that decrypts and displays the content. They can be reduced with strong security engineering, code review, audits, CSP, dependency controls, and transparent release processes.

The unavoidable trust line

End-to-end encryption removes the server database from the trust boundary. It does not remove the shipped client application from the trust boundary.

Trusted while open Browser UI Decryption code In-memory keys Not trusted with plaintext Database Backups Risk zone XSS Bad deploys Compromised devices Only encrypted data leaves Can attack client-side trust The app must decrypt somewhere so the user can read it. That “somewhere” is the browser.

Recommended product copy

Enable End-to-End Encryption
Your workspace content will be encrypted before it leaves your browser. We cannot read or recover encrypted content. You will receive a recovery key. If you lose access to your passkey and recovery key, this workspace may be permanently inaccessible.
Security note for enterprise buyers
This design greatly limits backend and database exposure, but web-based E2EE still depends on the integrity of the client app delivered to the browser. Strong deployment controls, code review, content security policy, dependency review, and audits are required to reduce that risk.

Implementation checklist

Keys
Generate workspace keys in the browser. Never store raw workspace keys in localStorage or on the server.
Storage
Store encrypted content and wrapped keys. IndexedDB is usually better than localStorage for app storage, but neither is a secure vault for raw keys.
Recovery
Give users a recovery key. Make the consequence of losing it extremely clear.
Auth
Use passkeys for sign-in and unlock UX. Keep the actual encryption key separate.
Frontend security
Treat XSS as a top-priority threat. Use strict CSP, sanitization, dependency controls, and minimal third-party scripts.
Governance
Protect the deployment pipeline. Internal code changes can affect the security model users rely on.

Created as a non-technical explainer for product, design, and client conversations.