Don't Take Our Word for It: Our Encryption Is Now Open Source
A file you send through VitalSend is encrypted before we ever see it, with a key we never receive. From today, you can verify that yourself instead of believing it.
Every service that claims end-to-end encryption asks you to believe the same sentence:
"We cannot read your files."
Usually, you just have to take their word for it.
We have published the encryption core of VitalSend so you don't have to take ours. It lives here:
This is not a demo, a sample, or a cleaned-up rewrite for show. It is the exact code the live service ships to your browser, extracted into a standalone package so it can be read, tested, and reused on its own.
What the claim actually is
When you send a file with VitalSend:
- The file is encrypted on your device, in your browser, before a single byte is uploaded
- The key is created on your device and placed in the share link, after the
#symbol. Browsers never send that part of a web address to any server - Whoever holds the link (and the optional password) can open the file. The server that stores it cannot
So our servers store locked boxes we have no key for. We cannot read your files. Neither can anyone who breaks into our servers, or compels us.
That is the claim. The repository is the evidence.
What's in the repository
- The complete code that locks and unlocks your files. It is built on libsodium, an encryption library trusted across the industry. Proven building blocks, nothing homemade. (For the technically curious: XChaCha20-Poly1305 authenticated encryption.)
- The key handling: how the key is created on your device, how it travels in the link, and how an optional password adds a second lock
- A byte-by-byte description of exactly what an encrypted file looks like, so nothing about the format is hidden
- A test suite that proves the guarantees instead of stating them: if anyone changes, removes, reorders, or adds even a single piece of an encrypted file, the download fails loudly. The tests demonstrate every one of those cases.
- Locked-down test files that guarantee the format can never quietly change underneath links that already exist
- A security document that lists what this code does not protect against, not only what it does
That last point matters to us. Most security pages only list strengths. Ours also lists limitations. A security claim that hides its limits is just marketing.
Why publishing this costs us nothing in security
A fair question: doesn't revealing the encryption help attackers?
No. If it did, the encryption would already be broken. Good encryption must stay secure even when everyone knows exactly how it works and the only secret left is the key. This principle is over a century old. Besides, our encryption runs in your browser, so the code was always visible to anyone who looked. Publishing it on GitHub made it easier to read. It didn't reveal anything new.
The only secret that matters is the key in your link. That key was never on our servers to begin with.
What open source does and doesn't prove
We want to be precise here, because this is where many security stories get vague.
Published code proves the encryption is designed right, and lets anyone check it. It does not, by itself, prove that the code your browser receives from us on any given day is that exact code. This is a known, honest limitation of all encryption that runs in a browser. We say so openly in the repository and in our threat model, and we are working on making that part independently checkable too.
If you find a hole in any of it, we have a coordinated disclosure policy with a safe harbour for good-faith research. The repository is explicitly in scope.
Read it, test it, use it
The code is free to use under the AGPL-3.0 open-source license. That is a strong copyleft license: anyone who builds our code into their own product or service must open source that product too. For companies where that does not work, a commercial license is available. It relies on a single, widely trusted library, never sends anything anywhere on its own, and processes files piece by piece, so your browser never needs to hold the whole file. We have tested transfers up to 1 TB on an ordinary Mac and PC.
If you're a developer: clone it, run the test suite, and watch the security guarantees verify themselves.
If you're not: we published it, and anyone in the world can check it. That is the point.