Zero knowledge

The phrase is a claim about who can read your data when nobody is watching. It is worth exactly as much as the answer to one question: can the service show you your own data after you forget your password?

Zero knowledge is a design where a service stores your data in a form it cannot read, because the key never leaves you.

What the phrase claims

In a zero knowledge design the encrypting and decrypting happen on your side, and what reaches the service is already unreadable to it. A dump of the whole database then yields shapes and dates rather than contents.

The word knowledge is doing the work. Not that the data is encrypted, which almost everyone can say truthfully, but that the party holding it has no way to turn it back into text.

How to test the claim

Four checks settle it faster than any page of description, and three of them you can run without reading a line of anyone's code.

The forgotten password test
If support can restore access to your data rather than to an empty account, somebody on that side holds a key.
Where the arithmetic runs
Encrypting on the server means the plain value arrived there first, whatever happened to it afterwards.
What a dump would show
A straight answer names the fields that stay readable, because in every real system some of them do.
The sharing question
Handing a secret to a teammate without the service ever seeing it is the hard part, and it is where most claims quietly end.

What never reaches our server

For the things that matter most here the question does not arise, because they are never sent at all.

Cookies and site data
They stay in the profile directory on the machine where the browser ran.
The sign-in pair of a profile
It is never sent, and a profile shared through the server arrives without it.
The one time code key
There is no column for it, so signing in elsewhere does not bring it along.
The fingerprint
It is not stored anywhere at all: it is derived at launch from the profile itself.

What the server does hold

While you are signed in, profile settings are mirrored so a second machine and your teammates see one list: name, group, scenario, fingerprint template and generation, proxy, tags and notes. Those are readable on our side, because a shared list has to be assembled somewhere.

Your account password is kept as a hash and never in plain form. A proxy password is sealed in the database with a key kept outside it, which protects a stolen dump and does not protect against somebody holding both.

Where this product stands

We do not describe ARMANOS as zero knowledge, because the settings above are readable to us and a forgotten password is recoverable by email. Saying otherwise would fail the first test on this page.

For the archives that carry your sessions the outcome is the same by a different route. They are encrypted with a key stretched from your passphrase, they travel through a folder you own, and the passphrase never enters that folder.

Often confused with

End to end encryption
That is about a message between two people. Zero knowledge is about data at rest on somebody else's machine.
A no logs claim
It is a promise about what is thrown away, not about what could be read while it is there.
Encryption at rest
The data is scrambled, and the question of who holds the key is left open. That question is the whole difference.
A zero knowledge proof
A way to prove a statement without revealing what backs it. Marketing borrowed the words rather than the mathematics.

What this does not do

This product is not zero knowledge, and nothing here says it is. Profile settings mirrored while you are signed in are readable on our side.
A forgotten account password is recoverable by email. That alone rules the phrase out, and it is the trade a team product makes on purpose.
The proxy password in the database is sealed with a key kept outside it. Somebody holding both the dump and the key can read it.
A passphrase kept only by you cannot be recovered by anyone. That part behaves the way the phrase promises, and losing it closes those archives for good.

Check it

Every claim above has a file behind it, and most have a stand that fails when the claim stops being true.

No call that sends profile settings carries the sign-in pair, and the mirrored table has no column for it: apps/desktop/test/login-stays-local.js · apps/server/prisma/schema.prisma
The fingerprint is derived at launch rather than stored, and it comes out the same on both machines: packages/shared/src/index.js · apps/server/test/отпечаток-один-и-тот-же.js
A session archive travels under your passphrase, and the passphrase does not travel with it: apps/desktop/src/lib/sessionSync.js · apps/desktop/test/session-sync-folder.js
The account password is kept as a hash, and the second step is single use: apps/server/src/auth/auth.service.ts · apps/server/test/two-factor.js

Questions

Does zero knowledge just mean encrypted?: No. Encryption says the data is scrambled, while the phrase says who holds the key, and only the second answer tells you what a stolen database is worth.
Can you read my cookies?: They are never sent. Site data and the browser's own databases stay in the profile directory on your own machine.
Can you read my proxy password?: In the database it is sealed with a key kept outside the database. Somebody holding both can open it, and that is why the phrase does not fit here.
What about the archives in my sync folder?: They are encrypted with a key stretched from your passphrase, and the passphrase never enters the folder. Nobody else has a copy of it.
Why not build the product this way?: Some of it is built this way already, and the rest is the price of a shared list: a teammate's view has to be assembled from settings somebody can read.

Next to this

Read what the server is told

The security page names every value that leaves your machine, every value that stays, and each edge where a protection ends.

Read the security page The promise register