Designing Panah: What Happens When You Refuse to Hold the Image
- BY
- ROOT TEAM
- PUBLISHED
- AUGUST 28, 2026
- READING TIME
- 6 MIN READ
Most anti-abuse systems start at publication. Panah starts at the threat. The most important decision in the whole project was a refusal, not a feature.
There is a moment in every design conversation about online abuse where someone says, "We need to collect the evidence." It sounds responsible. It sounds thorough. And it is the exact moment where the system starts to become the thing it was built to protect against.
Panah is a national response system for online blackmail and image based abuse. It was designed for Pakistan, but the problem it addresses is universal. The brief was to protect a woman or girl from the moment she is threatened, contain the damage if publication happens, preserve evidence, and route the case to the right authority. All without exposing her further.
The constraint that made everything else possible was this: Panah would never hold the victim's intimate images. Not in an encrypted vault. Not temporarily. Not for analysis. Not at all.
The harm starts before publication
The standard approach to image based abuse is reactive. A victim reports. The content has already appeared. The system responds with takedown requests, platform reports, sometimes prosecution. This model has a blind spot, and the blind spot is where most of the actual harm lives.
The damage begins the moment someone says, "Do what I say, or I publish." That is the coercion. The fear. The extortion. It happens while the image is still private. A system that waits for publication only ever sees the aftermath.
In an honour based context, the threat does not need to be carried out to be devastating. "I will send this to your family" can be as destructive as actually sending it. The woman is already trapped. She has nowhere to go, no one she can tell, and no system designed to catch her at the moment the threat arrives.
Panah reframes the trigger. A credible threat, not a published image, becomes the entry point. The whole system activates when she says someone is threatening her. Not when proof of publication surfaces.
The image that must not be stored
This is the decision that defined everything else. A national archive linking identities to intimate images and abuse reports would be the most dangerous object in the ecosystem. A data breach or an insider threat could revictimize people at scale. In a context where honour killings follow exposure, the stakes are not abstract.
So the design refuses the image. On her phone, a secure fingerprint is created locally. Only the hash leaves the device, so platforms can block matches if the image ever appears. The picture itself never uploads. The system holds the threat evidence, messages, demands, usernames, richly and in detail. It refuses the photograph.
Every later decision follows from this refusal. The encrypted vault stores everything except the image. The referral packet contains evidence metadata but no image bytes. The audit trail proves what was and was not collected. The system is designed so that a breach would reveal threat correspondence and sender identities, never the material being weaponized.
The walkthrough
Consider a woman. Call her R. She receives a message. A private photo, and a demand for money by tomorrow night, or it goes to her family. She is not sure whether the photo is real or generated. She has told no one.
She opens Panah on her phone. There is no login, no name to give, and a leave quickly button in the corner in case someone glances over her shoulder. The first screen tells her, plainly, that she is not to blame. Before any form, it gives her three things that matter most. Do not pay. Do not send more. And let it help her lock her accounts.
Her phone makes a secure fingerprint of the image locally. The picture never leaves the device. Because no partnership is assumed, Panah guides her to the official blocking service rather than pretending to submit for her. She then seals the threatening messages and the sender's username into an encrypted, timestamped record. The app refuses to let her upload the private image itself, because it never needs to be stored.
A few quiet questions, one at a time, each skippable, establish that there is a deadline and a threat to contact her family. The risk engine marks the case High and flags it for a human. She reaches a confirmation screen. A case number. Three things already done. And a clear statement of what happens next, including that she will never have to repeat her story from scratch.
Every step R takes is written to a tamper evident record that independent oversight can verify. The promise to investigate the perpetrator without exposing the victim is enforced in the code, not merely stated in policy.
The risk engine that does not decide
Panah includes a transparent scoring model that tiers cases from Low to Critical. The factors are visible. A deadline. Repeated threats. Financial demands. Account access. Knowledge of the victim's family. Threats of violence.
But the model only assists. A minor forces a safeguarding pathway. A threat of violence forces human review. High risk cases never proceed on automation alone. The engine takes no action and names no one. It surfaces information for a human to act on.
This is not a limitation. It is the point. The system is designed to be useful to human decision makers, not to replace them. The most dangerous thing in a system handling intimate material and human vulnerability is the illusion of automation. Panah chooses explicit human checkpoints over the appearance of efficiency.
What was built and what was not
The buildable core was implemented and tested. The encrypted evidence vault. The tamper evident audit ledger. The explainable risk engine. The integration seam with its guided handoff default. And the referral packet generator. The safety guardrails were proven by the tests themselves. The vault refuses image data two different ways. A minor forces the safeguarding path. A threat of violence forces human review. The referral packet provably contains no image bytes.
What could not be built solo was equally clear. Real blocking network access, platform takedowns, and formal agency referral all require partnerships and institutional mandates. The design does not hide this behind claims of integration. It isolates it behind swappable adapters and states it plainly as the concrete ask of a government or institutional sponsor.
The same codebase serves a pilot today and a fully integrated system later. Only the adapters change.
The lesson
The strongest decision in the whole effort was a refusal rather than a feature. Protecting people from image based abuse tempts you, at every turn, to gather the very thing that endangers them. Every integration point whispers that you need the image to do your job. The discipline that made Panah trustworthy was keeping the image out, keeping humans in, keeping the limits honest, and measuring success by harm avoided, including harm the system itself might cause.
Less a clever system than a careful one.