RewindexArchive integrity
Archive integrity
Every record Rewindex captures goes into a daily checkpoint. Each checkpoint names the one before it and is timestamped by two independent authorities, so anyone can check that an archived incident or page version existed by a date and has not been changed since.
Covers what Rewindex captured live since October 17, 2026: 11,124 incident versions, 11,275 component status changes and 1,080 pricing, trust and legal page captures so far.
Older incident history came from vendors’ own published feeds and is not covered. The next checkpoint is made at 00:41 UTC.
What a checkpoint proves
- It proves that a record existed in the archive no later than its checkpoint’s timestamp, and that nobody, Rewindex included, has changed or removed it since. Changing any past record changes its day’s root, and because every checkpoint includes the previous one’s hash, every checkpoint after it would change too.
- It does not prove that the vendor served those exact bytes, or that the capture time is right: a record could have been made up before it was committed. Checkpoints are made every night, so that window is about a day at most for anything captured since October 17.
- Full vendor pages are not republished. For page captures, a proof contains the hash of the exact bytes captured, not the page itself, so anyone holding a copy of the page as captured can check it against the record.
Daily checkpoints
Newest first. Each one is a Merkle tree root over that day’s records, chained to the day before and timestamped (RFC 3161) by FreeTSA and DigiCert.
Check a record yourself
The “Check it in your browser” button under Archive proof on incident and change pages does steps 2 to 5 with your browser’s own SHA-256. To do every step on your own machine (bash, jq, openssl):
- Get the proof. Use “Download proof” on any incident or change page, or ask for one by record:
curl -s 'https://rewindex.com/integrity/proof.json?type=incident_version&key=…' -o proof.json - Content. For incident versions and component status changes, the archived bytes must hash to
payload_sha256in the record:jq -j .payload.text proof.json | sha256sum jq -r .record.record_json proof.json | jq -r .payload_sha256 - Record. The record’s hash, with a zero byte in front, is its leaf in the day’s tree:
{ printf '\x00'; jq -j .record.record_json proof.json; } | sha256sum jq -r .record.leaf_hash proof.json - Path. Combine the leaf with
.proof.audit_pathas in RFC 9162, section 2.1.3.2 (any Certificate Transparency library does this). The result must equalroot_hashinside.checkpoint.checkpoint_json. - Checkpoint. The checkpoint text hashes to
checkpoint_sha256, and itsprev_checkpoint_sha256is the previous day’s checkpoint hash (from/integrity/<day>.json):jq -j .checkpoint.checkpoint_json proof.json | sha256sum - Timestamps. Each token is signed by its authority over the checkpoint hash:
H=$(jq -r .checkpoint.checkpoint_sha256 proof.json) jq -r '.timestamps[] | select(.name=="FreeTSA") | .tsr_base64' proof.json | base64 -d > freetsa.tsr curl -sO https://freetsa.org/files/cacert.pem -sO https://freetsa.org/files/tsa.crt openssl ts -verify -digest "$H" -in freetsa.tsr -CAfile cacert.pem -untrusted tsa.crt jq -r '.timestamps[] | select(.name=="DigiCert") | .tsr_base64' proof.json | base64 -d > digicert.tsr openssl ts -verify -digest "$H" -in digicert.tsr -CAfile /etc/ssl/certs/ca-certificates.crt openssl ts -reply -in digicert.tsr -text | grep 'Time stamp'
Format
Enough to write your own checker.
- Records are JSON in the canonical form of RFC 8785 (sorted keys, no spaces), UTF-8, with times as
YYYY-MM-DDTHH:MM:SS.ffffffZand hashes as lowercase hex. Each states itstype,key, company,captured_atand the SHA-256 of its payload. - Payloads: incident versions are the canonical JSON of the incident as served by the vendor’s status page, including every update; component status changes are the canonical JSON of the component, its status and when it began; page captures are the page bytes as stored, with
raw_matchsaying whether they are exactly the bytes received. - Trees: one per UTC day, leaves ordered by capture time, then type, then key. Leaf hash is SHA-256 of
0x00followed by the record; inner nodes are SHA-256 of0x01, left and right (RFC 9162). - Checkpoints are canonical JSON with the day, cutoff, tree size, root hash, record counts and the previous checkpoint’s SHA-256. That SHA-256 is what the timestamp authorities sign.