How CuratorNote's browser-encrypted note model works

Threat boundary

A security model is useful only when it names the boundary it is trying to defend. CuratorNote's current design aims to prevent ordinary infrastructure storage from needing readable protected note content. Encryption happens in the browser, and the service stores or transports protected records alongside the metadata required to identify, order, and synchronize them. This is narrower and more testable than a blanket assertion that the service cannot see anything. Requests still travel through a network and authenticated application stack.

The model does not defend a user from every compromised endpoint. Malicious browser extensions, injected code, operating-system malware, an exposed master password, unlocked devices, or a person deliberately copying content can reveal plaintext at the moment it is displayed. Traffic analysis and operational logs may reveal timing, IP information, sizes, and identifiers. Security evaluation therefore needs to consider both encrypted storage and the environment in which decryption occurs. The browser is an active participant, not merely a neutral window onto a remote vault.

A useful review begins by listing assets and actors. Assets include readable notes, encryption material, account credentials, metadata, media, and exports. Actors include the account holder, collaborators, browser code, infrastructure services, and any outside provider that receives intentionally shared content. For each path, ask where plaintext exists, who authorizes access, what evidence remains, and how failure is surfaced. This exercise keeps the threat model connected to actual data flows rather than an abstract label.

Browser encryption

Protected content is encrypted before synchronization using browser cryptographic facilities. The Web Cryptography API provides standardized primitives, but a primitive alone does not guarantee a safe product. Key creation, derivation parameters, nonces, versioning, error behavior, serialization, and migration all have to be implemented consistently. CuratorNote's master-password gate controls access to browser-held encryption material. The application must be unlocked before readable protected records can be used in the interface.

A master password should be treated differently from an account login code. Email OTP or Google OAuth proves account access to the service, while the master-password flow unlocks protected workspace material. Conflating those roles would blur what the server authenticates and what the browser decrypts. Recovery is consequently constrained: a service that does not possess a usable decryption secret cannot simply reconstruct it after loss. Users must account for password quality, safe recovery practices, and the possibility that lost encryption material makes content unavailable.

Local-first storage

The application uses browser IndexedDB as a local-first store for its working data. Local-first here describes where the interactive copy lives; it does not promise that every feature works indefinitely without a network or that every conflict can resolve automatically. IndexedDB is a structured browser database with its own lifecycle. Browser profile deletion, storage pressure, privacy modes, device failure, and site-data clearing can remove it. A local copy is useful for responsiveness, but it should not be mistaken for an independent archival backup.

Local storage also affects the threat model. Plaintext must exist in memory when the user reads or edits an unlocked note, and protected material or derived state may persist according to implementation needs. Locking the workspace, closing tabs, and securing the device remain meaningful user actions. Multiple tabs or devices can produce concurrent changes, so synchronization needs stable identifiers and version behavior. The product's local-first design is a foundation for careful workflow, not a magic exemption from distributed-system tradeoffs.

Server-visible metadata

The service needs server-visible metadata to authenticate a request, find records, enforce ownership, order changes, and operate storage. This may include account-derived identifiers, record identifiers, timestamps, types, revision information, media attributes, request headers, IP-related security information, and ciphertext sizes. The exact set depends on the active endpoint. Encryption protects selected content fields; it does not automatically hide the shape and rhythm of service use. Documentation should keep this operational layer visible.

Authentication itself carries data. Email identity is normalized and represented using a salted hash for lookup, OTP verification uses a hashed code with an expiry, Google OAuth uses short-lived state, and browser sessions use an HttpOnly cookie. API keys are stored as hashes for verification. Cloudflare services provide the Worker execution and current D1, Durable Object, and R2 bindings. Each component performs a different role, so the broad phrase server storage should not be read as one uniform database with one uniform exposure.

Media handling

Media deserves separate attention because binary objects are large, can contain embedded metadata, and may use upload flows different from ordinary JSON records. The current architecture includes R2-backed media support and authenticated application routes. A secure implementation must decide which media bytes are encrypted before upload, which attributes remain visible for indexing or transfer, and how previews and object URLs are created and revoked. File names, MIME types, dimensions, and sizes can themselves disclose context even if payload bytes are protected.

Users should inspect files before upload and understand that downloaded or exported media leaves the browser workspace boundary. Local applications, preview tools, backups, and sharing actions can create additional copies. CuratorNote cannot protect a file after the user intentionally sends it elsewhere. Media migrations also require care because cryptographic formats and metadata schemas may evolve. A robust path should preserve version information, validate integrity, and fail clearly instead of silently presenting corrupt or incorrectly decrypted content.

Current limitations

The current model does not eliminate endpoint risk, metadata exposure, password loss, malicious dependencies, browser vulnerabilities, traffic observation, or mistakes in how an operator shares content. Encryption also does not establish that an AI provider can safely receive a note: any deliberate handoff of plaintext creates a new processing boundary that must be evaluated on its own terms. The public site therefore avoids security superlatives and does not claim certification, guaranteed breach prevention, or universal secrecy.

Operational policy complements the cryptographic model. The reviewed retention schedule, account-deletion procedure, backup lifecycle, controller identity, jurisdiction, transfer terms, and privacy channel come from the canonical approval record. Those are not cryptographic details, but they affect whether people can evaluate the complete service. The product should keep code, diagrams, and policy aligned as it changes. Readers should use the privacy policy alongside this technical boundary description.

Using the model responsibly

A practical user secures the browser profile, chooses a strong master password, keeps devices updated, limits extensions, verifies destinations before export, and understands which workflows disclose plaintext. Teams should decide who may unlock a workspace and how recovery material is handled. They should also review server-visible fields when introducing sensitive classifications. Technical controls are strongest when paired with understandable operating habits and a deliberate decision about what belongs in the system.

For a broader product view, read the overview of what CuratorNote is, the step-by-step How it works page, and the current Security page. These resources separate shipped behavior, principles, and roadmap direction. That separation is part of the model: a future control does not mitigate today's risk, and a design principle is not evidence that every code path implements it. Security documentation earns value by remaining specific enough to be corrected when the implementation changes.