Every source behind every claim

By conclusion

Third-party copies — an independent record, not always current

The weakness above is real: we could swap a file and the hash beside it in the same deploy, and nothing on this page would show it. 9 of the files below were submitted to the Wayback Machine after we first published them and verified byte-for-byte at submission time. Right now none of those 9 still match — every one of them has content that changed after it was archived (see the stale-copy note below), so this protection isn't live for any file at the moment. Re-archiving the current content is a planned next step, done separately from this change so the archive timestamp reflects an actual submission, not a claim we didn't make yet.

How we found this was worth doing: submitting to the Wayback Machine is also how we caught a real bug in our own hosting. This site invites readers to run sha256sum against the HTML evidence files and compare — and that promise had never actually held, because Cloudflare's edge injects a Web Analytics beacon script into every response served as text/html, adding bytes that were never in the file we published. Nobody had reported it; the archive comparison caught it because its verification is byte-for-byte, not "did the submission return 200". Fixed by publishing those files as .txt instead of .html — same bytes, an extension the edge doesn't rewrite.

What the archive copies do prove: that we had published the archived version of that file on zenonia.wiki before the archive's capture time. When the row is labeled "archived" that's also true of the file as it stands today; when it's labeled "archive of an earlier capture" it proves only the earlier version existed, not that today's file matches it. That's it.

What they don't prove:

• Not that Steam or Google answered this way — the archive captured our page, not their server. We fetched their API; the archive is a witness to what we published, not to what they said.
• Not tamper-proof or unforgeable. We can still swap the file and the hash beside it together. The archive doesn't stop that — it just leaves a mismatched copy sitting where anyone can find it afterward.
• The archive timestamp is an upper bound on publish time, not the fetch time. There's a gap between when we pulled the data and when we got around to submitting it for archiving; the archive only proves the content existed by the later moment.
• archive.org is itself a third party with its own crawl policy, rate limits, and uptime. It's a witness, not a cryptographic proof — it can be slow, refuse a submission, or go down. 15 of our 33 submissions did not verify at the time we made them; the reason for each is recorded, not hidden.
• An archive that verified at submission time can still go stale afterward — its content can change for more than one reason: a live/ file gets overwritten every time we re-run the request behind it, or an existing file's own bytes get edited (this round: normalizing line endings so the published hash matches what a fresh checkout actually serves — see the note above). Either way the archive keeps pointing at whatever we published at submission time, not at the current file. 9 of the 9 files that were both verified at submission time and are still published as an index entry below are in that state right now, so the archive for each is a genuine copy of an earlier capture, not of the content the file holds today. Those rows are labeled "archive of an earlier capture" instead of "archived" throughout this page, and their file listing above shows which ones. (The other 9 of the 18 files verified at submission time — raw response bodies and the live/ index itself — were never published as their own row below, so they don't appear in either count here.)

You don't have to trust our submission. Anyone can submit any URL on this site to https://web.archive.org/save/<url> themselves and get their own independent capture — you're not relying on us having done it honestly.

To check one yourself: open the archived copy (linked next to each request above), append id_ to its timestamp segment to get the unwrapped original bytes (archive.org sometimes serves those gzip-compressed — decompress first), and compare against the file on this page. On a row labeled "archived" they should match. On a row labeled "archive of an earlier capture" a difference is expected — that label means the archive still matches the content as published on its capture date, not the file as it stands today; if you see a mismatch there, that's the labeling working as intended, not a problem to report. Full method and per-file results: evidence/25.

Complete machine-readable index

Every source above, plus provenance, size and hash for all 63 files: /evidence/live/index.json (the 30 replayable requests) and the individual JSON envelope beside each file linked above (self-describing — request, timestamp, status, hashes, and what each does and doesn't prove).