Privacy

Your SaaS Shouldn't Know Your Secrets

Most software could read everything you put into it. It just promises not to. A better design removes the question entirely: build the app so it's technically unable to read your data, and trust stops being something you have to extend on faith.

Most software could read everything you put into it. It just promises not to. When you store a client's ID, a password, or a contract in a typical tool, the company behind it can technically open that data. You're trusting a promise, their security, their staff, and whoever might one day compel them.

A better design removes the question. Build the app so it is technically unable to read your data, and trust stops being something you have to extend on faith.

The quiet default of most software

Here's the arrangement almost everyone accepts without noticing. You hand your data to a service. The service can read it. You rely on the company's good intentions, its security team, and its lawyers to keep that data from being misused or handed over.

"Encrypted at rest" doesn't change this. It means your data is stored scrambled, but the provider still holds the keys. They can unscramble it any time, and so can anyone who gets hold of those keys. The lock is real; the provider just kept a copy of the key.

A different arrangement

There's another way to build software. With client-side encryption, data is scrambled on your device before it ever reaches the company, and the key stays with you and the people you choose. The provider ends up holding a box it can't open.

The consequences are concrete. If the company is breached, the attackers get scrambled data. If a court comes asking, there's nothing readable to produce. The provider isn't being trusted to resist those pressures, because it has nothing useful to give up.

Trust reduced, not magic

It's worth being honest about the limits, because overclaiming is its own red flag. You still trust the app's code to do the encryption correctly and not to be quietly changed to capture your keys. Trust moves to the software itself; it doesn't vanish.

But that's a far smaller thing to trust than "we have all your readable data and promise to be careful with it." The best version of a secrets tool is one that removes itself from the equation as much as the design allows.

Can the provider read it?

Model	Who holds the key	Can the provider read your data?
No encryption, or transit only	Provider	Yes
Encrypted at rest	Provider	Yes, it holds the keys
Client-side / zero-knowledge	You and the endpoints	No, it stores scrambled data

Where doconvoy fits

doconvoy is built on the third row. The readable version of your data never reaches its servers, because encryption happens in the browser and the keys don't land server-side. There's nothing readable to leak, mine, or hand over. And it stays honest about the part that remains: you're trusting the client code, not a policy about the server.

Encrypted in the browser, with nothing readable ever reaching our servers.

Software built not to see your data

Common questions

Can SaaS companies read the data I store with them?

Usually, yes. In most software, and even with 'encrypted at rest' storage, the provider holds the encryption keys, so it can read your data. It typically promises not to and secures it well, but the ability is there. Client-side encryption is the design that removes that ability.

Does 'encrypted at rest' mean the provider can't see my data?

No. Encrypted at rest means the data is stored in scrambled form, but the provider holds the keys, so it can still unscramble and read it. To keep data private from the provider itself, it has to be encrypted on your device before it's uploaded.

Is client-side encryption 'no trust required'?

Not quite, and it's worth being honest about it. You still trust the app's code to encrypt your data correctly and not to be tampered with. What you no longer trust is the server with your readable content, because the design keeps it off there. Trust is reduced, not erased.