Why we built a team workspace around one question: what does a fully compromised server learn?
Most “private” workspace tools protect your data with a promise. The promise lives in a privacy policy: we will not look, we will not sell, we will not share. It may be sincere. But a promise is only as strong as the people keeping it, the staff who can reach the database, and the next attacker who gets in.
lockORG takes a different approach. It is a workspace app (notes, kanban boards, tags, todos and a journal) for small teams and individuals, and everything in it is encrypted on your device before it is sent. The server stores it, syncs it, and never reads it. Nor can it.
That is the difference between a promise and a property. A promise can be broken. A property is how the system is built.
The one question asked of every change
Every change to lockORG is judged against a single question:
What does a fully compromised server learn?
The answer must not grow. Here is what it is today. Imagine someone has the whole database, the image files, the logs and the server configuration.
Look at the left column carefully. It is not empty, and we do not pretend it is. More on that below.
Why a weak password does not sink you
Most encrypted products have a quiet weakness: if your key comes only from your password, a stolen database can be attacked offline, guessing passwords as fast as hardware allows.
lockORG’s vault key is derived from two things: your password and a 128-bit account secret key. That secret key is generated on your device at sign-up, printed once in a recovery kit, and kept on your devices. The server never stores it. So even with a weak password, offline brute force against a stolen database is hopeless.
Your password is never sent to the server either. Signing in uses a separate value derived through a different path, so a leaked login credential says nothing about the key that opens your data.
Private means private, even from your admin
In a team workspace, the natural question is: can my admin read everything?
Shared material (notes, boards, tags) is encrypted under a workspace key that every verified member holds. But your todo list and your journal are encrypted under your personal key. Other members, admins included, hold no key for them. The server will not even address another member’s personal rows.
What we do not claim
Honesty about limits is part of the design, so here is the list we would rather say before anyone else does:
Not “military-grade”, “bank-level”, “unhackable” or “100% secure”. Those phrases do not describe anything checkable.
Not anonymous. The server knows your email, who is in which workspace, when you write and how much.
Not protected against a malicious operator shipping malicious JavaScript to your browser. This is the known limit of any web client. Native clients with pinned cryptography are the long-term answer.
Not recoverable without you. Lose your password and your recovery kit and your data is gone. Nobody, operator included, can bring it back. (An optional recovery key gives you a second way in, if you create one.)
No two-factor sign-in at launch. It is planned, not shipped.
No real-time co-editing. That is deliberate: it would mean either a server that sees content or a far more complex protocol.
Every claim is a test
A security page is easy to write. What makes lockORG’s claims worth something is that each one is backed by a test that fails when the property breaks: published cryptographic test vectors, an authorisation test covering every API route, generated tests that try to reach across workspaces through every endpoint, tests that search browser storage for secrets after sign-in, and mutation testing on the security-critical code.
The security model, the threat model and the protocol will all be published. The threat model lists, item by item, the risks that are accepted and cannot be fixed.
lockORG will also be open source once a solid foundation is in place and the basic functionality has been brutally tested with early users. Opening the code is not a substitute for good engineering; it is a way to make the engineering inspectable. You will be able to read what the application does, verify the claims against the implementation, and hold us to the promises we make.
When the time is right, we would rather be checked than trusted.
Top comments (0)