Code integrity for web apps: how to know the encryption running in your browser is the real one
In a zero-knowledge web app, the code doing the encryption is delivered at every page load. Here is why code integrity is the real threat model, and how continuous verification works.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
The honest weak point of every web-based encryption product If your files are encrypted in the browser, then the JavaScript performing that encryption is the security boundary. It is downloaded again on every visit. A provider that could silently serve modified code to one targeted user could, in principle, undermine the model for that user — no matter how strong the algorithms are.
Anyone selling browser-based encryption without discussing this is skipping the interesting part.
What "code integrity" means concretely It means the application can detect that the code running is the code that was published — and that everyone else is receiving the same build.
Three mechanisms combine: - A build manifest. Every shipped asset is hashed at build time; the app can compare what it loaded against that published list. - Fleet consensus. Independent clients report which build they are running. A version served to one person but nobody else is an anomaly by definition, and targeted attacks depend on being targeted. - Trust on first use, then pinning. The identity keys your device has already seen are pinned locally, so a substitution attempt is a visible change rather than a silent one.
Why key substitution is the attack that matters Rather than breaking encryption, the realistic attack is to make you encrypt to the wrong key: swap a recipient's public key, and the message is perfectly encrypted — to the attacker. DRIVUNO treats key resolution as fail-closed: an unexpected key change stops the operation instead of quietly continuing, and the local mirror of previously seen keys is cross-checked before anything is sealed.
What users can do - Install the app so the code is served from a locally cached bundle rather than fetched fresh each time. - Pay attention to key-change warnings; they are rare by design. - Use the published release timeline to see what changed and when.
What we publish A transparency page listing releases and operational changes, a threat model that names the residual risks rather than hiding them, and an integrity state visible from the app itself.
The takeaway Strong cryptography is table stakes. The distinguishing question for a web app is: *how would I notice if the code changed?* If a provider has no answer, the encryption claim is unverifiable.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.