Screening Images at Volume Without Breaking Privacy
Client-side analysis and high-throughput screening seem incompatible. They are not — the architecture just has to change shape.
Our detector analyses one image at a time in a browser tab. That is exactly right for a journalist checking a single photograph, and exactly wrong for a moderation team facing ten thousand images a day.
Volume users ask us for an API. The interesting part is that the obvious API would destroy the property that makes the tool worth using.
The tension
A conventional REST endpoint means uploading images to our servers. That reintroduces every problem client-side analysis was built to avoid: transmission, retention, jurisdiction, breach surface. For the very organisations most likely to need volume screening — platforms handling reported intimate imagery, insurers handling claimant data — that is not a trade they can make.
Three architectures that preserve the property
1. Local batch in the browser. The same engine, iterating over a folder the user selects via the File System Access API. Nothing leaves the machine. Throughput is bounded by the operator’s hardware, but for a few thousand images overnight that is entirely adequate.
2. A library the customer runs. Ship the analysis engine as a package the customer deploys inside their own infrastructure. Images never leave their perimeter; we never see them. Their compute, their retention policy, their jurisdiction.
3. Perceptual-hash exchange. For matching against known-bad corpora, exchange hashes rather than images. The hash reveals nothing recoverable about the picture, but allows matching. This is how existing industry hash-sharing programmes work.
Each keeps the guarantee intact. Each is more work than a simple upload endpoint, which is why most services do not do it.
What we are building
Local batch first, because it needs no infrastructure on either side and serves the largest group of people asking. A self-hosted library follows, for teams that need screening inside an existing pipeline.
We are not planning a hosted upload API. If we ever build one it will be a clearly separate product with an explicit, prominent data-handling statement — not a quiet extension of a tool whose entire premise is that we never receive your files.
If you need this now
Tell us your throughput, your latency requirement, where your images live, and what your compliance constraints are. Those four answers determine which of the three architectures fits, and the honest answer is sometimes that a specialist vendor suits you better than we do.
We would rather point you somewhere appropriate than sell you the wrong shape of tool.