What the Workers are allowed to see

Claim: the edge has a permission list, not a trust speech

Most products describe their cloud as “encrypted” and stop there. Transport is TLS. Disks are encrypted at rest. Dashboards show green checkmarks. Those controls matter. They are not a vault security model.

NT² Vault’s edge claim is narrower and more useful: Cloudflare Workers are allowed to see account and billing facts, public identity material, and opaque ciphertext frames—and nothing that lets them read your vault.

That is a permission list. The Workers that sit behind api.nt2.me may:

• register a cloud account keyed by a Vault Key DID and store public verification material;
• issue a short challenge, verify a signature, and mint a session for sync and relay routes;
• accept and return opaque replica batches and attachment frames;
• keep entitlement and billing state so Premium sync can be enforced without opening items;
• index share-relay delivery metadata (who sent ciphertext to whom, expiry, view limits)—never decrypted fields.

They may not:

• receive the master password;
• hold KDF salt or a password verifier that turns a database dump into an offline guessing rig;
• decrypt item payloads, attachment bytes, or inbox envelopes;
• become a searchable cloud copy of titles, notes, credentials, or document numbers;
• treat unlock on se.nt2.me as a server login that fetches enough material to open the attic.

Zero-knowledge, for this product, means blind by construction: the schemas and routes do not contain columns or endpoints that would require the edge to understand vault contents. If a feature needs plaintext, it runs on the device that already has the key.

Constraint: “helpful” edges become readable vaults

The pressure to expand what Workers see is continuous and usually well-intentioned.

Support wants “just the latest five item titles” so a ticket can be triaged. Analytics wants plaintext categories for funnels. Recovery wants a server-held salt so a new phone can “just work.” Search wants deterministic tokens so the cloud can answer queries. An admin console wants a “view vault” button because every other SaaS has one.

Each request sounds like a small exception. Together they recreate the architecture we refused: a cloud application that happens to store some ciphertext on the side.

There is a second constraint that is easy to understate: origins and environments. A staging Worker that accepts production vault traffic, or a production API that still exposes a legacy salt fetch “for migration,” collapses the permission list in practice even if the marketing page still says zero-knowledge. Staging and production must be separate hosts with separate bindings. Production public surfaces are plain: the vault app at se.nt2.me, the API at api.nt2.me, marketing at nt2.me, and this blog at blog.nt2.me. Staging lives on Cloudflare’s Workers staging hosts—useful for operators, not a second production attic for user secrets. Clients must not be taught to call the wrong environment “just this once.”

The constraint is therefore twofold:

1. Capability: do not give the edge the data that would let it become a vault reader.
2. Topology: do not blur staging and production so that “temporary” paths become permanent trust holes.

If either fails, the permission list is theater.

Design: two schemas, one blind relay

NT² keeps two different worlds of data.

On the device, the vault is a structured local database: items, attachment metadata, inbox, contacts, sync cursors, and local-only unlock material. Decryption is transient and in memory. The list is paged and searched locally. Unlock derives keys on the client; lock clears them.

On the edge, the service is an account and relay layer. A Cloudflare D1 account row holds service identity and entitlement facts—not vault plaintext. Replica coordination for Premium sync is keyed by Vault Key DID so one identity maps to one sync hub. Object storage holds ciphertext bytes under opaque identifiers. Share relay stores delivery metadata and ciphertext blobs for blind delivery. WebSocket notifies say “something changed,” not “here is a preview of your passport title.”

The unit that crosses the network for sync is an opaque frame inside a replica batch—same family of sealed bytes that a portable backup uses. The Worker stores, orders, and returns frames. It does not interpret them as bank names, note bodies, or credential URLs.

flowchart LR
  subgraph device [Device]
    Unlock[Local unlock]
    Vault[(Local vault)]
    Encrypt[Encrypt before upload]
  end

  subgraph edge [Edge Workers]
    Auth[Key DID session]
    Meta[(Account / billing metadata)]
    Frames[Opaque sync frames]
  end

  Unlock --> Vault
  Vault --> Encrypt
  Encrypt --> Auth
  Auth --> Meta
  Auth --> Frames

Authentication reinforces the split. Opening the vault is a local event: password (or other local factor) derives keys on the device. Talking to the cloud is a different event: the unlocked vault proves identity with a challenge–response signature over a Vault Key DID. The server learns that a public identity is present and authorized. It does not learn the master password, and it does not need salt to verify the signature.

Billing fits the same discipline. A merchant-of-record flow may attach a billing email for receipts. That address is not vault identity, not unlock material, and not a lookup key for decrypting frames. Premium is an entitlement flag on an account, not a license to index secrets.

The design rule that keeps this honest is negative: if a column would help someone who stole the database open or search a vault, the column does not ship. Account identity and public keys stay. Password-checkable unlock material stays on the device. Ciphertext stays ciphertext.

Trade-off: less server magic, more user-held custody

Blind Workers are inconvenient for classic SaaS habits.

Support cannot open the vault. An operator can see service health, auth failures, entitlement state, object counts, and timing. They cannot click into a readable item to explain a strange note. That is not an unfinished admin feature. It is the edge refusing to become a plaintext control room. Users who need human help must describe symptoms without pasting secrets into a ticket that the server could have filled automatically—because the server never had them.

Password reset is not a Workers feature. If every unlock factor and every user-held recovery path is gone, the edge cannot invent them. There is no “email me a reset link that re-derives your vault key.” That refusal is paired with portable backups and local salt: ownership includes custody.

New-device onboarding needs out-of-band material. Salt and profile sections travel with the user—backup file, recovery kit, or replica handoff—not via a convenient GET that re-centralizes password-checkable state. Sync can move opaque frames after enrollment; it cannot replace enrollment with a cloud fetch of unlock oracles.

Product analytics stay coarse. Funnel metrics that require plaintext titles or decrypted categories do not get a free pass because “we would only store hashes.” Deterministic tokens that make vault contents searchable on the server are still a vault index on the server. Prefer device-side measurement and coarse account events.

Environment discipline is operational work. Separate staging Workers hosts, separate production origins, and clients that refuse to mix them cost configuration care. The payoff is auditability: reviewers can ask “what can this Worker see?” and get an answer that does not depend on hoping nobody pointed production UI at staging storage.

What we gain is a boundary you can state in one sentence and verify in schema review: the edge relays and accounts; the device understands. Compromise of the account database or object store is still serious—ciphertext and metadata are user data—but it is not automatically a plaintext breach or an offline password lab.

What we refuse

We refuse a salt or password-verifier escrow on Workers. Unlock material lives in the local vault profile. The edge binds identity; it does not assemble a guessing system.

We refuse plaintext item APIs “for sync convenience.” Sync moves opaque batches and attachment frames. There is no cloud table of readable titles that “helps” conflict resolution.

We refuse support tooling that decrypts vault contents. Health and entitlement visibility yes; “view vault” no.

We refuse collapsing unlock and cloud login into one server round-trip. Local derivation and Key DID challenge–response stay separate events with separate failure modes.

We refuse staging–production shortcuts that widen what Workers see. Temporary migration endpoints, shared databases across environments, or clients hard-coded to the wrong origin are treated as security bugs, not conveniences.

We refuse billing identity as vault identity. Optional receipt email is not a master-password reset channel and not a substitute for Vault Key DID auth.

We refuse notification payloads that preview secrets. “New encrypted frames are available” is enough. Titles and categories wait for local decrypt.

These refusals are how the permission list survives roadmap pressure. Every declined feature is a column that never appears in D1 and a log line that never contains a note body.

Blind on purpose

The Workers behind NT² are not a miniature vault in the sky. They are an optional edge: identity, entitlement, opaque replica transport, and blind share delivery. The attic stays on the device you unlock at se.nt2.me. Production origins stay named and separated so that claim is checkable, not atmospheric.

That boundary is the same story told from different doors. How unlock differs from cloud auth is Unlocking a local vault is not logging in to the cloud. How replica frames stay opaque is Blind replica sync on the edge. How one Vault Key DID maps to one sync hub is One sync hub for one vault identity. Why the account table must not become a password oracle is The account database must not become a password oracle. Why salt never becomes a cloud fetch is The KDF salt stays on your device.

If you want a vault whose cloud layer is allowed to see only what a blind relay needs—try NT² Vault or read more at nt2.me.