Privacy architecture & policy
Tomozi is designed so the server can operate your workspace without reading the authored content inside it. Privacy is not one setting; it is the boundary every feature must pass.
The trust model
Not everything can be encrypted in the same way. Tomozi separates authored content, necessary operations, and explicit disclosures instead of hiding that distinction.
Encrypted in the trusted client with record-bound authenticated envelopes before persistence.
Kept server-readable only where authentication, authorization, scheduling, relationships, limits, or payment require it.
Selected plaintext may leave the E2EE storage boundary only for the action you approve—such as an AI request, public share, notification, payment, or verification.
A record’s journey
A note, task, file, decision, or other workspace record begins in your browser.
A random record key and authenticated entity/ID binding protect the content.
The API, database, object store, backups, and logs never receive the content key.
The active client unwraps and decrypts only what you are authorized to open.
Vault goes further
Vault combines your in-memory workspace key with an independently authorized server-held share. The raw Vault Encryption Key and every item key stay out of backend plaintext storage.
AI with a visible boundary
AI does not crawl the encrypted workspace. The unlocked browser selects and decrypts only approved records, sends the minimum request-scoped plaintext, and encrypts anything chosen for persistence.
Services and processors
Providers are used for distinct operational purposes. Workspace plaintext does not become general billing, analytics, notification, or marketing data.
Ciphertext, account records, relationships, scheduling and other required operational metadata.
Opaque encrypted File, Note-image, Canvas, Document, Meeting, People, and Vault objects.
Only the plaintext you explicitly approve for that request; provider credentials remain in a separate protected boundary.
Hosted checkout and provider-authoritative subscription/payment lifecycle. Tomozi does not handle card numbers.
Generic reminder text and routing metadata—not your encrypted reminder or workspace content.
The minimum phone-verification material needed for an explicit welcome-credit claim.
Only after you allow analytics: public page visits, controlled interaction labels, referral/campaign attribution, and standard device or coarse-location measurement. Never email, form values, workspace content, or encryption material.
Your controls
Your passphrase or recovery key unlocks the workspace. Tomozi cannot reconstruct forgotten raw keys from stored ciphertext.
Private/public sharing is explicit and capability-based. Fragment-held share keys do not reach the API.
Permanent domain deletion removes the record and releases its quota. Required security and billing records follow their operational lifecycle.
A preregistration email is server-readable only for launch contact. It does not create an account or enter your encrypted workspace.
Google Analytics stays unloaded until you allow it. Declining sends no analytics request; you can revisit the choice from the footer without affecting waitlist or product access.
An unlocked device, browser extension, malware, or compromised client can access content visible in that active client. Use trusted devices, keep recovery material offline, and lock Tomozi when you step away.
A system worthy of your memory
Explore the product, review the terms, or reserve your place in the first circle.