Protecting the Record — and the People Behind It

But an archive documenting killings, prisoners and people facing execution in Iran has another responsibility: protecting the people connected to that evidence.

A name in this archive may have a family still inside Iran. A photograph may contain information its sender never realised was there. A correction may come from somebody who cannot safely identify themselves. A document useful for verification may contain information that should never appear on the public website.

For that reason, security and privacy are not features we added after building the archive. They are part of how the archive is designed.

We also want to be clear about the limit of that statement.

No website can promise complete anonymity or absolute security.

Our approach is therefore simple: collect as little identifying information as possible, separate private submissions from the public archive, restrict access, remove unnecessary metadata, encrypt sensitive files, and give people control over what becomes public.

You do not need to identify yourself

You do not need an account to read The Iran Massacre.

You also do not need an account to submit a name, send evidence or request a correction.

A contributor's name and email address are optional. If identifying yourself could create a risk, we ask you to leave those fields blank.

We do not ask contributors for home addresses or national identification numbers.

The principle is deliberate:

If we do not need a piece of personal information, we should not collect it.

We do not keep visitors' raw IP addresses

The archive does not retain visitors' raw IP addresses.

Like any public website, however, we have to defend submission forms against automated abuse and attacks. For that purpose the system uses a one-way representation of an address rather than storing the original IP.

It is designed for abuse prevention, not for identifying visitors.

The public site also does not require tracking cookies simply to read it.

Preferences such as language, theme, low-data mode and saved names can remain on the visitor's own device. A session cookie is required only when somebody chooses to sign in.

Evidence files are not the same as public files

One of the most important distinctions in the system is between evidence submitted to the archive and material approved for publication.

Uploading a photograph or document does not automatically publish it.

Files submitted through the website for verification are encrypted on the server when they arrive. Access to submissions is restricted to authorised editors and administrators.

Volunteers do not have general access to private submissions.

Publication is a separate decision.

A person can therefore provide material that helps us verify a record without automatically agreeing to have that material displayed publicly.

Photographs can reveal more than the photograph

Digital photographs may contain metadata recording information such as location, time and the device used to take the picture.

That information can be dangerous.

The submission form therefore offers removal of location metadata from photographs before they are sent, with that protection enabled by default.

There is another safeguard on the server.

Photographs that editors work with, or that are eventually published, are recreated as fresh copies without the original camera and location metadata.

The original submitted file, where retained for verification, remains separate from the public copy.

Video requires additional care because the same server-side cleaning does not currently apply to video files. Contributors should remove sensitive metadata themselves where possible before submitting video.

Third-party content does not load automatically

An archive like this inevitably links to material on other platforms.

But loading an embedded Instagram post, YouTube video, TikTok or Telegram content can cause the visitor's browser to communicate with that third-party service.

For that reason, external embedded media is not loaded merely because somebody opens a page.

The visitor chooses when to load it.

Only then may the third-party platform receive information or set cookies according to its own policies.

This is particularly important for visitors who do not want unnecessary connections to external services while browsing the archive.

The public website is hardened at the browser level

The live site uses HTTPS and security policies intended to reduce common web-based attacks.

These include HTTP Strict Transport Security, restrictions on where scripts can load from, protection against the site being placed inside hostile frames, a restrictive referrer policy, and browser permissions that disable access to features such as geolocation, camera and microphone where the site does not need them.

Cloudflare is also used as part of the public-facing network and attack-protection layer.

These controls do not make a website invulnerable. They reduce exposure and provide layers of defence.

Security is not one switch. It is a series of barriers.

Administrative access is separate from public access

The public archive and its management functions have very different trust requirements.

Private submissions can be accessed only through authenticated management functions. Editors and administrators use password-protected accounts with two-step sign-in.

Automated research tools can propose matches, identify possible duplicates and surface evidence, but they cannot simply publish their findings.

Automation proposes. People decide.

Every public change is subject to human review.

This is a security measure as much as an editorial one. Compromising an automated process should not be enough to rewrite the public historical record.

We deliberately protect living people differently

The archive increasingly documents not only people who were killed, but prisoners and people facing execution.

That requires additional safeguards.

Before publishing material naming a living prisoner or somebody facing execution, editors are required to consider whether publication could harm that person, their family or their legal defence.

Home addresses, telephone numbers, national identification details, workplaces and unnecessarily identifying information about relatives should not be published.

Information supplied privately by families or through submissions does not become public merely because the archive possesses it.

Where appropriate, records can also be kept away from search engines or certain social-media publication functions.

The question is not simply:

“Is this information true?”

It is also:

“Could publishing this information hurt someone?”

Families can ask us to hide information

The archive exists to preserve people's identities, not to take ownership of them.

Families can ask us to correct information, add information or remove material.

A request to hide a record can remove it from public view while the request is reviewed.

Corrections and merges are recorded rather than silently rewriting the history of the database.

That matters because an accountable archive should preserve not only evidence, but also the history of how conclusions were reached.

Government sources are evidence, not authority

Security also means protecting the integrity of the archive itself.

The Iran Massacre does not allow one organisation, government or automated system to become the sole authority over the record.

We compare human-rights reports, news reports, family information, witnesses, open-source material and other archives.

Government lists may be used to cross-check information, but they are not treated as independent confirmation.

Likewise, AI-generated or community-compiled lists may generate leads, but a lead is not the same thing as verified evidence.

The provenance of information matters.

What Cloudflare can — and cannot — protect

We use Cloudflare as part of the site's public-facing infrastructure. It provides an additional layer between ordinary web visitors and the hosting server and helps defend the public website against automated attacks and abusive traffic.

But we do not describe this as “making the site anonymous”.

That would be misleading.

Infrastructure security has limitations, and some services — particularly email and administrative services — have different technical requirements from the public website.

Our aim is defence in depth, not a claim that the infrastructure can never be identified or attacked.

If you are inside Iran

This deserves its own warning.

We cannot promise that using this website from inside Iran is risk-free.

No VPN, browser setting, encrypted website or privacy feature can provide that guarantee.

Reading the archive does not require an account or email address. If you submit information, you can leave your identity and contact information blank.

Where possible, use public links as evidence rather than sending something that identifies you. Be careful with photographs and videos that may contain location information.

And never send us identifying information simply because a form gives you the option to do so.

If providing something could put you, a victim's family or another person at risk, do not send it.

The completeness of this archive is never more important than someone's safety.

Security is an ongoing process

The archive is still developing.

That means our security model must develop with it.

New features create new risks. New forms of evidence create new privacy questions. Features involving prisoners and people facing execution require different safeguards from a historical list of those killed.

We will continue reviewing those risks as the archive grows.

When we discover a problem, the goal is not to pretend it never existed. It is to fix it, document what matters, and improve the system.

The same principle that governs our evidence should govern our security:

Do not claim more than the evidence supports.

The Iran Massacre exists because people deserve a record that can be examined.

Protecting that record also means protecting the people who help us build it.