Verify the Code This Site Serves You

ztrash’s central claim (mail sealed in your browser’s keys, a server that can’t read it) ultimately rests on the JavaScript this site serves you. An unverifiable claim is marketing. This page is the first checkable step: every deploy publishes a manifest of SHA-256 hashes for every file the site serves, both on the site itself and as a timestamped record in a public transparency repository, pushed before the deploy goes live.

Where the records live

The running site serves its own manifest at /.well-known/integrity.json. The out-of-band copy lives in a public records-only repository, codeberg.org/ztrash/transparency, as <git-commit>.json. The manifest names the commit, so it tells you which record to compare against. The two are the same file, extracted from the exact image that shipped: any drift between them is a checkable lie.

Check it yourself

Raw commands first, because you shouldn’t have to trust our tooling to distrust our server. Fetch the served manifest and the public record, and compare them byte for byte.

Set ORIGIN to the host you are actually reading this on. If you came in over Tor, keep it as your .onion address: verifying the clearnet site from a Tor session both checks the wrong host and makes a clearnet request you probably did not want to make.

ORIGIN=https://ztrash.com  # or http://<your>.onion

curl -sS "$ORIGIN/.well-known/integrity.json" -o manifest.json
COMMIT=$(jq -r .git_commit manifest.json)
curl -sS "https://codeberg.org/ztrash/transparency/raw/branch/main/$COMMIT.json" \
  -o manifest.repo.json
cmp manifest.json manifest.repo.json

Then hash what you’re actually served against the manifest:

jq -r '.assets | to_entries[] | "\(.value) \(.key)"' manifest.json |
while read -r hash path; do
  echo "$hash  $(curl -sS "$ORIGIN$path" | shasum -a 256 | cut -d' ' -f1)"
done

Every line should print the same hash twice. The transparency repository also carries a small dependency-free verifier (verify-integrity.mts) that runs the same checks: a convenience, deliberately second to the raw commands.

What this proves

That the bytes served to your fetch match a public, timestamped record the operator committed to before they went live. The site can’t quietly serve different code without leaving checkable evidence.

What this does not prove

Honesty about the limits is the point, so plainly: it is not build provenance. The application source is not public, so the commit id names a version you cannot inspect. And even with the source open, without fully reproducible builds you could not rebuild it and byte-compare. The manifest is a commitment to exactly what is served, timestamped, not proof of what it was compiled from. And it does not rule out per-user targeting: a malicious server could serve clean files to your verification fetch and a poisoned bundle to your session. If that is your threat model, verify the bytes your own session received (DevTools → Network → save the response bodies and hash those). And note that long-lived asset caching means your browser may legitimately be running an older bundle recorded in an older manifest. None of this says anything about the server side; for what the server stores and doesn’t, see the no-log guide.

What’s next

Listed so you can hold us to it: deterministic, reproducible frontend builds and opening the source (together those would turn this commitment into provenance), and an independent audit of the sealing design. Until then, this page claims exactly what the mechanism delivers and nothing more.

Generate an inbox →