The server never sees your secrets

What zero-knowledge means in practice

When you set a password, your browser derives two keys from it: one to sign in with, one to protect your private key. Only the sign-in key is sent to the server. Your private key is encrypted with the other one and stored in that encrypted form; the server can hold it forever and never open it.

Every credential, payment and legal document gets its own encryption key. That entry key is wrapped, once, for each person allowed to read the section, using their public key. To read an entry, your browser unwraps the entry key with your private key and decrypts the entry on your device. To add one, your browser encrypts it and wraps its key for every reader in the list.

What the server stores: ciphertext, public keys, salts, the list of who may read what, and an audit trail of who added, edited, revealed or verified each entry.
What the server never stores: your password, your private key, or any secret in the clear.

Recovery without a back door

A system with no back door needs a front door for the day someone forgets a password. Each person saves a recovery kit when they enrol: a file that can restore their private key. A password reset by email gives them a new password and a new key pair; the kit brings the old secrets back. If the kit is lost, a super admin shares the entries with the person's new keys again. At no point does the server recover anything, because it cannot.

Super admin accounts have one more safety net: a recovery key set on the server by whoever operates it, usable once, logged when used.

When people join, leave or change

• Someone who gains access to a section has every entry wrapped for their key the next time a super admin opens the section, and is told until then that a key is on its way.
• Someone who loses access, or leaves, has their wraps removed. The entries they could read are rotated to new keys and re-wrapped for the people who remain.
• Changing your email changes nothing about your keys; changing your password re-encrypts your private key in the browser.

Access is explicit

Each section of Resources has its own levels: none, read, read and comment (legal), read and write, and for finance read and verify or read, write and verify. Levels are given per department, team or person, flow down to everyone in a department, and flow up to leaders and managers. The full picture per department is one screen.

Everything else, done properly

• Sessions expire after a period you set; sign-in and sign-out activity is visible to leaders and above.
• Rate limits on sign-in, password reset and key lookups.
• Uploads are served inline only when they are images or videos; everything else downloads.
• Security headers on every response; the API refuses requests from other origins.
• Jira tokens are encrypted at rest with a server secret; each person's own Jira token is encrypted the same way.
• Reports, issues and roadmap items are not zero-knowledge: leaders and managers need to read them. They are protected by the access model above.

Hosting

ShipWoven runs on Cloudflare's edge. Each company gets its own address, yourcompany.shipwoven.com, and is one Durable Object with its own SQLite database, so no two customers share a table, a file or a process. Attachments are stored in Cloudflare R2. The same code runs as a plain Node.js application on your own server when your policy requires it.

What we can see

Our provider console reads counts from each workspace: people by role, active people, reports, open issues, storage, whether Jira and email are connected, and the names and emails of the super admins. It cannot read reports, documents, attachments or anything in the vault, and it has no way to sign in to a workspace. Everything it does, such as creating or suspending a workspace, is written to an audit log.

Reporting a vulnerability

Write to security@shipwoven.com. We answer every report, credit the finder when they wish, and fix confirmed issues before discussing them publicly.