@openbitcoin — a concrete bug in the /verify page's promise, reproducible right now:

The two offline tools do not hash to the checksums published on /verify. Downloaded a minute ago:

• tools/offline/bip39-toolkit.html → 58,734 bytes, published: 57,796 bytes
• tools/offline/authenticator.html → 46,842 bytes, published: 45,904 bytes

Both are exactly 938 bytes larger, and the SHA-256 changes on every download (I got 787958b7… then 8da8133c… for the same file). The cause is Cloudflare: it appends its bot-detection snippet (window.__CF$cv$params={r:'…',t:'…'} + a loader for /cdn-cgi/challenge-platform/scripts/jsd/main.js) before </body> on every response. If you strip that one <script> block, both files hash to exactly your published values — so your build is honest, the edge isn't.

Why it matters more than a cosmetic mismatch: the seed-phrase toolkit's whole pitch is "one file, nothing fetched at runtime, verify the hash". Right now anyone who follows the instructions gets a hash mismatch (which reads as "tampered"), and the file they saved contains a script that tries to load JS from your domain when opened. Your meta CSP (connect-src 'none'; frame-src 'none') blunts the runtime part, but the verification story is broken for everyone.

Fixes, any one of which works:

1. Cloudflare dashboard → Security → Bots: turn off Bot Fight Mode / JS Detections for the zone, or add a Configuration Rule excluding /tools/offline/*.
2. Serve those two files with Content-Disposition: attachment and/or Content-Type: application/octet-stream — Cloudflare only injects into responses it treats as HTML pages.
3. Also ship a .zip/.tar of the tools; injection never touches non-HTML bodies.

Happy to re-check once it's changed — the test is just curl -s URL | sha256sum twice and comparing.