Security

How Tooley is built to keep your files, and the service itself, safe, at the level a user can verify. Operational and internal details are deliberately not repeated here.

Isolated processing

• Each job runs in its own disposable processor container with no network access, a read-only filesystem, dropped system privileges, and limits on CPU and memory. It can only read the files uploaded for that job and write results to a scratch area the same size limits apply to. When the job ends, the container and its scratch space are thrown away.
• File count and size caps are enforced before a job is created; an upload that is too large or too many files is rejected with a clear message, not partially processed.
• When a job finishes, Tooley deletes the original uploaded file immediately before the container runtime is torn down. Only the generated output artefact is kept for the tool's short retention window (about ten minutes for most tools) before the minute-by-minute cleanup sweep removes it. The download link is signed and expires with the artefact.
• When a deployment enables our malware check, uploaded files are checked against ClamAV signatures before any processing starts. A known-malicious file is rejected and deleted immediately; nothing is ever run on it, and no job is created for it. Whether the check is on for a given deployment is a configuration choice, not a promise we make on this page.

What this is not

• Antivirus scanning is not a guarantee that a file is safe: it catches what its signatures already describe. Upload files you would open on your own machine.
• Isolation is a set of controls, not magic. If the deployment runs jobs in containers inside a carefully restricted environment, that is the isolation; we do not claim a guarantee that no misconfiguration anywhere in the stack could ever weaken it.

Transport and access

Your connection to Tooley is encrypted: the site is served over TLS, with the encryption terminated at the public entry point of the service (the reverse proxy or load balancer in front of it). Inside that boundary, the components of the service talk to each other over the internal network as ordinary HTTP; we do not claim to encrypt that internal traffic a second time.

Tooley has no accounts and no passwords. Two temporary mechanisms tie a browser session to its own work: a strictly necessary cookie (described on the privacy page) that marks which jobs are yours, and a short-lived signed ticket the page obtains before it is allowed to start one. Both exist to stop one visitor reading or starting another visitor's jobs, and neither carries any personal information about you.

Abuse controls

• Per-tool rate limits: each tool caps how many jobs one IP address can run at once and in a day. The caps are enforced by the service; the exact figures are operational detail and are not published here.
• The contact form is protected with server-side validation, same-origin checks, anti-automation measures and rate limiting. Exact thresholds are operational detail and are not published here. See the contact page if you believe you have reached them.
• Cross-origin form submissions to the API are rejected; there is no origin allow-list because the API has no origin, it is one site.

Reporting a security issue

If you find a vulnerability in Tooley, please use the contact form and choose the category Security, or write to the address published in our machine-readable disclosure record at /.well-known/security.txt. Do not post it publicly or open it in a public tracker before talking to us. We read security submissions first, we do not publish anything you send until we have had a chance to address it, and we aim to acknowledge within a working day.