Verify the code. Every build, every time.

Every Henedo production build emits a transparency manifest, a JSON document listing the SHA-384 hash of every JavaScript, CSS, and WASM asset in the build. The manifest is:

• Signed with an Ed25519 key held as a secret in our CI build environment. It is never deployed to a runtime server, but it is not air-gapped either: whoever controls the build pipeline can sign.
• Published to the transparency_manifests table, publicly readable.
• Applied as SRI integrity attributes on matching local script and stylesheet tags in the generated HTML.

Your browser enforces SRI when it loads resources carrying an integrity attribute. For an additional audit, use “Verify this build” below to check the signed manifest and compare fetched JavaScript assets with it. This optional check runs only when you request it. A deployment change or unavailable resource can make an audit inconclusive; a mismatch alone does not establish that code was tampered with.

• SRI blocks a modified script or stylesheet when its bytes differ from the integrity hash in the page.
• A signed manifest lets auditors detect changes to assets after signing.
• Comparing assets with a trusted manifest can reveal inconsistent or modified deployments.

• A compromise of our CI build pipeline, which holds the signing key and can therefore sign a malicious build.
• A compromised server that replaces both the page and its verifier. Independent verification requires a trusted public key and verifier.
• A browser extension that modifies page content after SRI verification.
• A physically compromised user device.

Any external auditor or browser extension can verify any Henedo build independently:

1. SELECT manifest_json, signature FROM transparency_manifests WHERE build_id = ?
2. Verify the Ed25519 signature over manifest_json with the known public key.
3. Fetch each asset URL from our CDN and compute SHA-384.
4. Compare against the manifest and investigate any mismatch, including deployment changes.

The public signing key is published at /.well-known/transparency-key.pub. Auditors, security researchers, and browser extensions are welcome to cross-check against our published log.

Our first formal third-party audit is scheduled for Q3 2026, and the architecture is already open for review today. Until the audit firm is contracted (we publish their name when we sign), what an external auditor or browser extension can verify right now is the part of the story we control completely:

• Architecture spec: SECURITY.md and BACKEND_ARCHITECTURE.md, public, maintained, line-by-line citable.
• Signed builds: every production deploy publishes its manifest to the public log; the auditor workflow above runs in any browser.
• Bug bounty: $5K to $25K paid for confirmed issues, see the security page.
• Source-level disclosures: the cryptographic primitives we depend on, with their library versions, on the security page.

Most launches ask you to wait for an audit before they document anything. We document first; the audit confirms what is already in the open.

Your data is engineered to survive any single point of failure, including ours. The transparency log is one half of that promise; the export architecture is the other.

The signing public key is embedded in every Henedo build, so any cached copy of the app remains independently verifiable. Manifests already published are public records. If Henedo ever winds down, the log mirrors to a successor archive so future auditors can verify any historical build.

For your data itself: retain the complete encrypted export, its full decryption keys and the offline reader. Together they support independent recovery. The current Eternal purchase is a cloud archive; physical delivery is specific to older contracts. See the portability page.

The full security architecture (including zero-knowledge encryption, Argon2id key derivation, device-bound ASK, WebAuthn PRF, Shamir secret sharing, and canary-blob breach detection) is documented on the security page. The fault-isolation argument for the bundled product is on the architecture page.