Security

What is true today.

Last updated 2 August 2026

Security pages usually describe an aspiration. This one describes what is actually running, and says plainly what is not built yet, because a product asking to hold your whole life should not be vague about which parts exist.

What is real right now

Encryption in the browser The intake tool derives a key from your passphrase using PBKDF2-SHA256 at 310,000 iterations, and that key wraps a fresh random data key which encrypts your file with AES-GCM. Only the wrapped key is ever written into the file. Your passphrase is not.

We cannot open it Because the passphrase never leaves your browser and is never stored anywhere, losing it means the file cannot be opened, by you or by us. That is the cost of the promise being real.

Nothing is transmitted The intake tool sends nothing. Once the page has loaded it makes no network request at all: not while you type, not when you seal the file, not when you download it. Open the Network tab and use the whole tool with it open. The list stays empty.

No third parties No page on this site loads anything from another company. No fonts from a CDN, no tag managers, no third-party trackers, and no advertising network. Every request a page makes goes to this domain.

What we do count, and where it goes The marketing pages count page views and named button presses so we can tell whether the site works. That request goes to this domain and nowhere else, and the database it lands in has no column for an IP address, a device, a browser string, or a full web address, so those cannot be recorded even by accident. We store the page path, the name of the button, the country your connection resolves to, and a random identifier this browser generated for itself. There is no scroll tracking, no session recording, and no profile. Automated browsers are not counted at all, so our own test runs never appear as visits. The intake tool and the composer are counted not at all. Neither one sends an analytics request of any kind, on any press, and the Network tab will show you that.

What the composer sends Composing a view, editing it and sealing it make no network request at all. Pressing Create the link makes exactly one, and pressing End this share makes one more. Open that request and read it. It carries the sealed view, which is ciphertext, and five things we can read because holding the view for you needs them: the label you typed, the kind of view it is, how long the link should last, the access code if you set one, and a random token this browser invented, which is the only thing that can end the share. So we do learn that someone shared a medical view, and we cannot learn what is in it. The key that decrypts it never leaves your browser: it travels only in the part of the link after the #, which browsers never send to a server, so what reaches us is a box we were never given a key to. That one request is slowed per IP address at the edge, so a loop cannot hammer it. Your address is used for that brake and nothing else here: the analytics database has no column to record it in.

Transport HTTPS everywhere, HSTS with preload, and a set of hardening headers including X-Frame-Options DENY and a strict referrer policy.

What is not built yet

Continuum does not yet have accounts, sync between devices, or a server that holds your file. Your file stays in your browser and on your own disk. When those parts exist, this page will describe them before they ship.

Sharing is built and it is live. This paragraph used to say it was not, while the composer was sealing real views and handing out real links from a page this one links to in its own footer. Composing a view, sealing it, sharing it and ending that share all work now, on your own records.

So there is one thing we do hold, and it is worth being exact about. It is never your file. It is one composed view, made for one decision: an AES-GCM envelope we cannot open, with the label and the kind of view readable beside it, the access code if you set one, and the token that proves the share is yours to end. It is held for as long as you chose when you made the link. The choices offered today are one hour, one day and thirty days, and adding another one is a change to this page as much as to that menu. Ending the share deletes those bytes, after which the server answers every later request for them with “not available” — the same answer it gives for a link that never existed. What is fictional is the preview's file — the records in it belong to nobody and it says so on every screen — not the sharing machinery underneath it.

We hold no security certification. We are not SOC 2 audited and we are not going to describe ourselves as HIPAA compliant, because neither is true today and both are claims people make loosely. When an audit is complete, the report will be named here with its date and its scope.

Reporting a vulnerability

Email security@reddenda.com. Please include enough detail to reproduce the issue. We will acknowledge within three business days and keep you updated until it is resolved.

We will not pursue legal action against anyone who reports a genuine issue in good faith, gives us reasonable time to fix it, and does not access, modify or destroy data belonging to another person while investigating. There is no bug bounty programme yet, and we will say so here when there is rather than implying one exists.

Machine-readable contact details are at /.well-known/security.txt.

How we work

There is one sanctioned way to publish this site, the script at scripts/deploy.sh, and it refuses to publish if any of four checks fail: a wrong passphrase must not decrypt a file and must leak no partial plaintext; a sealed file must be an AES-GCM envelope at rest with no record text in the clear beside it; the intake tool's encryption must really happen in your browser; and no page may request anything from another company. The last two drive the built pages in a real browser. They stop the deploy itself: this site is assembled and published from one machine by that script, so there is no build server in between for a test to fail on.

What that does not cover, said plainly, because a security page that only lists its guards is describing an aspiration again. The share round trip — create a link, open it as the recipient, end it — needs the deployed server functions to mean anything, so its test runs against the live site by hand rather than inside the publish path. The script also has an explicit switch to skip the checks, and anyone holding the hosting token can push bytes without the script at all. So this paragraph describes what our publish path does. It is not a claim that no bytes can reach the server any other way.