Signed Web Page Archiving for Journalists and Fact-Checkers with Verifiable Captures

The problem: evidence that disappears or cannot be trusted

A politician's post is deleted an hour after it goes viral. A company quietly edits a press release. A government notice changes without any note. Journalists and fact-checkers in Pakistan and across South Asia deal with this every week, and the usual answer is a screenshot. Screenshots are easy to fake, so the other side calls them fake, and the argument moves away from the facts. Fact-checkers then spend their time defending the screenshot instead of checking the claim, and readers are left unsure who to believe.

Public web archives help, but not always in time, and not for everything. Some pages block them, captures happen on someone else's schedule, and a newsroom cannot easily prove that it captured a page itself at a specific moment.

What already exists and the gap

• The Internet Archive's Wayback Machine captures a huge share of the public web, but it is a third party and does not record who requested a capture as evidence.
• Perma.cc, run by the Harvard Library Innovation Lab, creates permanent links for courts and journals, mainly for institutions in its network.
• Webrecorder tools such as ArchiveWeb.page and Browsertrix capture high-quality archives in the open WACZ format and have published a draft specification for signing and verifying WACZ files.
• Screenshots with metadata can be edited easily.

The gap is a simple, self-hostable newsroom tool that combines high-fidelity capture, signing, trusted timestamps and a verification page any reader can use, with a workflow suited to small teams.

Inspiration

Webrecorder's WACZ Signing and Verification specification describes how to sign a web archive package so its creator can be proven, using either an anonymous key or a domain-name identity with an RFC 3161 timestamp. Your project implements that specification end to end in a tool built for journalists, and tests how well it survives real-world tampering attempts.

What you build

• Reporters paste a link or press a button in their browser to capture a page. The capture is signed with the newsroom's key and timestamped.
• Editors see all captures with notes, who made them and when.
• Readers and courts open the public verification page, load a file and see whether it is intact, who signed it and the trusted time of signing.

The technically interesting part

• High-fidelity capture. Modern pages load content with JavaScript, infinite scroll and lazy images. Use a real browser, scroll and wait, and record every request and response, not just the final HTML.
• What to sign. Sign a hash of the package's index of files, as the draft specifies, so any change to any resource breaks verification.
• Keys and identity. Decide how a newsroom's key is tied to its domain, how keys rotate, and what happens if one is stolen.
• Trusted time. A signature alone does not prove when it was made. Add a timestamp from an independent authority and verify it on the verification page.
• Long-term verification. A file checked in five years must still verify after keys have rotated or expired. Record the certificate chain and timestamp token inside the package, and test verification with an expired key.
• Replay without leaks. The replay must never fetch from the live site, or a later edit could leak into the evidence.

How to evaluate it

• Fidelity: capture 100 pages of different types (news, social posts, government notices) and score how complete each replay is.
• Tamper detection: make 50 kinds of edit to captured files and show every one fails verification.
• Speed: time from clicking capture to a signed file.
• File size and storage: average package size per page type, and the storage cost of a year of captures for a small newsroom.
• Usability: ask two or three journalists or student journalists to capture and verify pages, and record where they get stuck.

Suggested plan

• Weeks 1 to 4: read the WACZ and signing specifications, run Browsertrix and ArchiveWeb.page.
• Weeks 5 to 10: capture service, packaging and signing.
• Weeks 11 to 15: timestamps, verification page and replay.
• Weeks 16 to 20: team features, the extension and tamper tests.
• Weeks 21 to 26: user testing with journalists, write-up and demo.

Path to a product

Newsrooms, fact-checking groups, human rights organisations and law firms all need trustworthy captures. A free self-hosted edition and a hosted edition for small newsrooms is a realistic model, and press freedom groups fund tools like this. The project is also a strong portfolio piece for security and backend roles.

Scope warning

Do not write your own crawler or archive format; build on Webrecorder's open tools and specifications. Do not attempt to capture content behind logins in the first version, because that raises privacy and terms-of-service questions. Get capture, signing and verification working well for public pages first.

Learn what you need on Sefism

• Cybersecurity roadmap: hashing, signatures and key management.
• Backend development roadmap: the capture service, queues and storage.
• Backend development cheat sheet: quick reference while building the service.
• Playwright Documentation: browser automation for captures.
• OWASP Cheat Sheet Series: key storage and cryptography guidance.

Get help with this idea

The risk is a tool that captures pages well but cannot prove anything, or proves things nobody can verify. Tauseef can help you plan the signing design, the tamper tests and a user study with real journalists. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session