Encrypted before sync
XChaCha20-Poly1305 protects current notes, documents, tasks, media, and albums before their protected payload reaches UNIIC infrastructure.
Back to UNIIC
Implemented E2EE MVP Not independently audited
Security model · 17 July 2026
What UNIIC protects. And what it does not.
Protected workspace content is encrypted in your browser before local persistence, sync, or media upload. Identity, operational metadata, and the web application delivery path remain part of the trust boundary.
Identity is not decryption
Google and Supabase authenticate the account. The 24-word recovery phrase remains the offline secret that derives the vault hierarchy.
Links are capabilities
The decryption secret stays after #. Anyone holding the complete link can use its current permission and forward it.
The data boundary
Encrypted content is not invisible infrastructure.
Content confidentiality and metadata privacy are different claims. UNIIC protects the readable payload, while providers still operate the account, database, requests, shares, and storage.
Protected as ciphertext
- Note and document titles and content
- Task text, dates, subtasks, layouts, and settings
- Media filenames, MIME types, album names, and file bytes
- Object, file, album, and share key envelopes
Still visible as metadata
- Account identity, email/profile data, device/session activity, IP, and user agent
- Object types, identifiers, versions, timestamps, sizes, and deletion state
- Album relationships, storage paths, encrypted-byte usage, and quota
- Share mode, expiration, revocation, request timing, and traffic size
Provider visibility
Who sees what, during normal operation.
Can see
Your Google identity and OAuth activity.
Not sent by the current client
Recovery words, Privacy Lock words, vault keys, or protected content from UNIIC.
Supabase
Can see
Account/session data, ciphertext records, operational metadata, shares, paths, and quota.
Not sent by the current client
Readable protected text, names, MIME types, file bytes, or usable content keys.
Storage
Can see
Opaque object paths, ciphertext sizes, access relationships, and request timing.
Not sent by the current client
Plaintext media bytes, filenames, MIME types, album names, or raw file keys.
Vercel / UNIIC
Can see
Requests, identity, IP/user agent, operational metadata, ciphertext, and wrapped keys.
Not sent by the current client
Protected plaintext or raw vault/content keys during normal operation.
Threats covered
What E2EE changes.
- A leaked database, storage object, or server backup reveals ciphertext rather than protected content.
- A Google/Supabase account identity alone is not enough to derive the vault keys.
- Modified ciphertext, the wrong key, or the wrong authenticated context fails decryption.
- A share exposes only the capability intentionally wrapped for that link.
Threats not covered
Where trust still remains.
- A malicious UNIIC deployment or same-origin XSS can read an unlocked browser.
- A compromised extension, browser, operating system, or unattended unlocked device can capture plaintext.
- A recipient can copy, download, screenshot, retain, or forward content they were allowed to open.
- Traffic timing, sizes, identifiers, relationships, and other operational metadata remain visible.
Local access
Privacy Lock and Device Unlock do different jobs.
Three BIP-39 words act only as an in-session Privacy Lock. Its Argon2id verifier may be guessed offline after a browser-database theft, but it does not wrap the persistent vault keys. Strong Device Unlock restores those keys with a WebAuthn PRF secret protected by the authenticator.
Standard Device Unlock uses normal WebAuthn user verification plus a non-exportable HMAC key in this browser profile. Interested users with a supported provider can opt into Strong PRF protection in Security settings. PRF is an enhancement, not a requirement for a protected vault state. The 24-word phrase remains the universal recovery path.
Sharing semantics
A complete link is a bearer secret.
The decryption secret is placed after #, which browsers normally do not include in the server request. Anyone who receives the complete link can use its current view or edit permission.
Temporary links stop future retrieval after expiration. Permanent links work until revoked. Neither action can retract plaintext that a recipient already viewed, downloaded, or copied.
For the current document edit flow, any signed-in UNIIC user with the complete edit link can submit an encrypted replacement. There is no named access list, author attribution, or real-time merge yet.
Current limits
Claims stop where evidence stops.
01
No independent security audit or formal verification
02
Session revocation cannot erase offline browser data, remove Device Unlock envelopes, or rotate keys
03
No complete encrypted backup/import or clean-browser restore drill
04
No encrypted history, complete rollback protection, or real-time CRDT collaboration
05
No guaranteed secure erasure from browser memory, recipients, or provider backups
06
Media is currently limited to 100 MiB and encrypted as a whole file in browser memory
The honest status
Real client-side encryption. Real limits. No audit badge yet.
UNIIC is suitable for product testing and continued security engineering. It should not yet be treated as independently verified or recommended for high-risk use.