Is the JavaScript you are running really the JavaScript we built?
This page verifies, in your own browser, that every JavaScript bundle ExistBefore is serving right now is byte-identical to the manifest the build pipeline signed off on at deploy time. The check runs locally — no telemetry, no server-side aggregation.
Per-asset verification
Manifest metadata
How this audit works
- Your browser fetches
/integrity.json, a manifest emitted by the build pipeline. The manifest lists every JavaScript bundle under/assets/together with its expectedsha256-<base64>SRI digest, its byte size, and the git commit + tag the build was produced from. - For each bundle in the manifest, your browser fetches the bundle, computes its SHA-256 with WebCrypto, and compares the result to the manifest entry. A mismatch means the bytes you executed are not the bytes we shipped.
- The check is purely client-side. The result is rendered above; nothing is sent to any server. This is the executable equivalent of the
integrity=attribute the browser already enforces on every<script>.
Why we publish this page
- Verifiable transparency. Anyone — auditor, journalist, regulator, security researcher — can confirm at any moment that the bundle being served is the one we signed off on. No need to trust our word, our deploy logs, or our CI status badges.
- Detection of origin compromise. If an attacker swaps a bundle without also rewriting the manifest, the audit will flag the mismatch. If they rewrite both, the published out-of-band manifest hash (in CHANGELOG and on a CertiSigma attestation) will differ from the served one.
- Forensic alignment. ExistBefore publishes content-integrity proofs. It would be embarrassing if the JavaScript that produces those proofs were itself unverifiable. This page closes the loop.
Out-of-band manifest verification
Every release publishes the SHA-256 of /integrity.json in two independent places: the CHANGELOG on GitHub and a CertiSigma attestation at the time of deploy. To confirm that the manifest itself has not been tampered with on this server, compare the SRI shown above (audit.meta.manifest_sri) with either source. If they disagree, the served /integrity.json is suspect even when this audit reports valid.