A threat model, not a badge

The safest copy of a document is the one that was never made.

This page sets out what the architecture protects you from, what it does not, and where the boundary sits. A security page that only lists strengths is an advertisement. The second half of this one is the part worth reading.

  • No upload endpoint
  • No storage
  • CSP default-src self
  • AES-256 in the tab

The claim in one line

If this site were fully compromised tomorrow, an attacker would gain the ability to serve you different code. They would not gain a single document, because none were ever sent.

And the limit

That same compromise would be serious for a different reason: code running in your tab has access to the files you open with it. Integrity of the served page is therefore the control that matters most, which is why the CSP is strict and the dependency list is short.

Part one

Six properties you can verify this afternoon

Each of these is a fact about the deployment rather than a policy. A policy can be changed by a product decision; a missing endpoint cannot be changed by anything except writing one.

There is no upload endpoint

The codebase contains no route that accepts a file. Not disabled, not gated — absent. A request cannot be made to a handler that was never written.

No document is ever stored

Files live in JavaScript memory as ArrayBuffers and are released when the tab closes or reloads. There is no bucket, no cache of documents, no local database of your files.

No accounts, so no identity store

No passwords, no email addresses, no session tokens. The most valuable database a service can hold is the one listing who its users are, and this one does not exist.

No third-party scripts

Every response carries a Content-Security-Policy with default-src ’self’. An analytics beacon or an ad script would be blocked by the browser before it loaded.

Fonts are self-hosted

Four woff2 files are served from this origin. Nothing on the site contacts a font CDN, which is a small request that most sites leak and this one does not.

Static hosting, no application server

There is no server process to compromise, no database to exfiltrate, no shell to obtain. The deployment is HTML, JavaScript, WASM and fonts.

Part two

Threats removed by the architecture

A breach at the vendor

There is no vendor copy. A breach could expose the marketing site and nothing else.

Insider access to your document

No employee, contractor or support agent can open a file they were never sent.

Retention mistakes

Backups, crash dumps, orphaned objects and misconfigured lifecycle rules all require a stored copy to expose.

A subpoena or data request

There is no document to produce and no account record to correlate. The only logs are ordinary web access logs.

Interception in transit

Your document does not transit. There is no upload to intercept, and no download to tamper with.

Accidental publication

The classic failure mode — one bucket set to public — needs a bucket. There is not one.

Notice what these have in common: they are all failure modes of storing something. Remove the storage and the entire category disappears, without any of the controls that ordinarily surround it — encryption at rest, access reviews, retention automation, breach notification procedures.

Part three

What this cannot protect you from

Seven threats, none of which are solved by client-side processing. Reading this list is more useful than reading the previous one, because these are the situations where a document actually leaks.

A compromised device
Malware, a keylogger or spyware on your machine sees everything you see. Local processing does not and cannot defend against a hostile endpoint, because the endpoint is you.
A malicious browser extension
An extension with file or page access can read the document, the password field, or the rendered canvas. Only you can audit what is installed in your browser.
A shared or borrowed computer
Downloaded files persist in the Downloads folder and browser history records the file names. Ream removes the network copy; it cannot remove the local one.
Screenshots, screen recording, over-the-shoulder
Once a document is on screen, it can be photographed. No software control changes that.
The file before and after
The original and the result live on your disk under your own access controls. If those controls are weak, the file is weak regardless of which tool produced it.
The browser engine and the supply chain
The site depends on pinned npm packages and on your browser’s implementation of WebAssembly, Canvas and Web Crypto. A vulnerability in either layer is a vulnerability here, and neither is under this project’s control.
The AI provider, when you supply a key
Summarise and Translate send extracted text directly from your browser to the endpoint you choose, authenticated with your key. That transfer is between you and them, under their terms — not this site’s.

Part four

The two operations where the detail matters

Encryption and redaction are the security tools people actually use, and both are routinely misdescribed. Here is precisely what each does, including where it stops.

Protect PDF

  • AES-256 through the PDF standard security handler.
  • Key derived from your password inside the tab; nothing stored or sent.
  • No escrow and no recovery — a lost password is a lost document.
  • Permission flags are advisory. The open password is the real lock.

Redact PDF

  • Marked pages are re-rendered as an image with the region filled in.
  • The characters underneath do not exist in the output file at all.
  • Unmarked pages keep their original, selectable text layer.
  • The cost: rasterised text is no longer selectable, and the file grows.

Before you send a redacted file

Open the output, select all, and copy. If the removed text does not paste, it is gone. Run OCR on the output and search for the redacted string; if nothing is found, the pixels are the only record. Both checks take ten seconds and are worth doing for any document you are about to send outside your organisation.

Dependency posture

Runtime dependencies are pinned to exact versions rather than ranges, so an update is a deliberate commit and not something that arrives overnight. There is no script tag pointing at a CDN, no tag manager and no remotely loaded font. The attack surface is the list of things in the lockfile and nothing else.

The offline test is a security test

Load a tool, then disable the network and run it. If it completes, there was no transfer. That is a stronger demonstration than any statement on this page, and it takes about four seconds.

how to run that test

Part five

Reporting a problem

If you find a way to make this site send a document anywhere, that is the most serious bug it is possible to report. It is worth more attention than any other issue in the tracker.

hello@ream.tools

Please do not open a public issue with a working proof of concept. Write first, and include the browser and version.

What to include

The page, the browser and version, and the steps that reproduce the problem. A recording of the network panel is ideal.

What to expect

An acknowledgement, an honest assessment, and a fix if the report holds up. There is no bug bounty — this is a small project and saying otherwise would be dishonest.

Disclosure

Reports are credited in the changelog unless you ask otherwise. Publication of a working exploit before a fix is not something this project can defend against, so please allow a reasonable window first.

Straight answers

The security questions that get asked

If an answer here is wrong, the email above is the fastest way to get it corrected. That is treated as a security fix, not an argument.

If nothing is uploaded, why does the site need HTTPS?
Integrity, not confidentiality of your document. TLS ensures the JavaScript, WASM and fonts you receive are the ones the server sent and have not been altered in transit. Without it, an attacker on the network could inject code into the page — which would be worse than reading a file, because it would run with full access to your tab.
How does the encryption work?
Protect PDF writes the document using the PDF standard security handler with AES-256. The key is derived from the password you type, inside the tab, using the platform’s cryptographic primitives. The password is never stored, logged or transmitted, and there is no key escrow — which also means nobody, including this project, can recover a document whose password is lost.
Can permission restrictions stop someone copying text?
Treat the permission flags as a request rather than a lock. Well-behaved readers honour “no printing” and “no copying”; a determined reader, or a different library, can ignore them. The real lock is the open password. This is a property of the PDF format, not a shortcut taken here.
Is the redaction real, or a black rectangle?
Real, in the specific sense that matters: any page containing a marked region is re-rendered as an image with the region filled, then written as a new page. The underlying characters are not present in the output file at all, so text extraction and copy-paste return nothing. Pages without marks keep their original text layer, and the tool reports exactly how many pages were rasterised.
What is the honest cost of that approach?
A rasterised page is an image, so its text stops being selectable and its file size grows. At 200 DPI it is fine for reading; use 300 DPI if the output will be printed. That trade is disclosed before the run, because a redaction tool that hides its mechanism is worse than useless.
Do you have a security certification?
No. ISO 27001 certifies the controls an organisation applies to data it holds; this project holds none, so there is nothing to audit in that sense. Claiming a badge here would be theatre. What can be checked instead is the architecture, which is why every claim on this page is testable in a browser.

The four-second audit

Turn off the network and use it anyway.

Every claim on this page reduces to one observation: open a tool, disconnect, process a file. If it works, the document did not go anywhere.

no uploadno storageno account