Security

The threat model, stated plainly

This page is written for whoever has to decide whether other people may use this site for documents that must not be uploaded. The product rests on one rule: files, file names, text inputs and results never leave the browser. Below is how that rule is enforced, who enforces it, where it stops, and how to tell us when it fails.

Four layers, in order of how little they trust us

  • Enforced by the browser, not by us

    Tool routes are served a content-security policy of connect-src 'none', which switches off every way a page can open a network connection at once. It is applied by the browser engine, so it holds even against a bug in our own code.

  • Enforced at build time

    The test suite scans the engine, worker, component and route source for direct network primitives and literal remote addresses, and fails the build when one appears. A tool cannot quietly acquire an upload path between releases.

  • Enforced per release

    An executable protocol attempts five exfiltration vectors, then runs a real file through a real tool and measures the bytes that left. It runs in two browser engines against the production build.

  • Open to inspection

    The source, the policy and the protocol are public and MIT licensed. Nothing above requires taking our word: each control can be read, run and re-run by you.

The measured result of the third layer — which vector was attempted, what the browser did, and how many bytes left during a real file operation — is published with the build and date it belongs to on the proof page.

One route differs, deliberately. The background remover must download its model and WebAssembly runtime before it can run, so it is served a policy permitting this origin and no other. Those downloads are application assets, like scripts and fonts. They contain no user data and travel towards the browser, not away from it. Any asset download that carries user content is a vulnerability under the list below.

What counts as a vulnerability here

These are not feature requests to be weighed against a roadmap. Each one is a defect to be fixed before other work:

  • Any network request carrying user file bytes, file names, pasted text, outputs, or anything derived from them.
  • Any client-side analytics, telemetry, session replay, advertising, fingerprinting or third-party tracking script.
  • Any server-side logging beyond the published visit log, or a visit log recording more than is published.
  • Any silent fallback from local processing to a remote service.
  • A support or payment flow that receives file, job or result data, or that withholds a local result.
  • A content-security-policy regression on a tool route — loosening connect-src, for example.
  • Classic web vulnerabilities: cross-site scripting, injection, unsafe cross-document messaging, supply-chain compromise or malicious dependencies.

A confirmed egress or undisclosed-telemetry finding is handled as critical: the affected tool is disabled or patched ahead of everything else, a regression test joins the suite so it cannot return unnoticed, and the fix is published as a security advisory crediting the reporter unless they prefer otherwise.

What this page does not claim

A security page that claims to have thought of everything is telling you it has not been read carefully. The controls above establish where bytes go. They cannot establish that no flaw exists, and no amount of egress evidence ever could — which is why phrases like “zero data leaks” were removed from this product rather than defended. Out of scope:

  • The security of your own device, browser, extensions or operating system.
  • Standard request records kept by the hosting provider, which every website has.
  • The correctness of a tool’s output. A wrong result is a bug, and welcome, but it is not a security report.
  • Missing hardening headers with no demonstrated impact, and findings produced only by an automated scanner without a working reproduction.

Reporting something

Please do not open a public issue for a security report. Use GitHub’s private vulnerability reporting on the repository’s Security tab.

What to include

  • The affected route or tool, and your browser and version.
  • Steps to reproduce.
  • For an egress report: the request address and method, plus a redacted network export or screenshot showing the payload. Never attach a real personal document — use a synthetic test file.

Acknowledgement

Within 72 hours

Triage decision

Within 7 days

Security fixes go to the latest commit on the main branch and to the live site. There are no supported older versions, because there is nothing to install and every visitor is already on the current one. The full policy is .github/SECURITY.md in the repository.

If you are assessing this for an organisation

Three things usually settle it, and you can confirm all three without contacting anyone:

  1. 1Read the response headers on any tool page and confirm the connection policy for yourself.
  2. 2Put a synthetic file through a tool with the network tab open, or with the network switched off entirely.
  3. 3Clone the repository and run the egress protocol yourself against whichever build you intend to allow.

Allow-listing this domain grants no outbound path for file contents. What the site records about a visit, in full, is on the privacy page.