Security & trust
The engineers behind taleseal have spent their careers securing UK critical national infrastructure. On those systems a security failure is a national story, not a bug ticket. A tale is a page you hand to a customer or a teammate, so it gets the same discipline: every control on this page is live in the running service, and you can check most of them from your own terminal.
live in production · checkable with curl · no asterisks
Don’t take our word for it
curl -sI https://taleseal.comHSTS, a strict content-security policy and no-referrer, on every responsecurl https://taleseal.com/.well-known/security.txtour disclosure policy, machine-readable01The link is the only door
A tale’s address is unguessable. Guessing at the permitted request rate would take millions of years. There is no other way in: readers need no account, and the only place your tales are listed or searched is your own dashboard, behind your sign-in.
No public feed exists anywhere in the product. Every tale page tells crawlers not to index or archive it, and tells shared caches never to keep a copy.
Links inside a tale are followed with no referrer, so the tale’s own address is never handed to the sites it links to.
02Your page, your switch
A tale starts as a draft, bannered as one until you publish. After that, readers see only the revision you published: a new draft behind the same link stays invisible until you publish it too.
A publisher can retract a tale: every version is destroyed at once and the address answers 410 Gone, permanently. The address is never reused, so a link can never start telling a different story.
A tale published with an expiry stops being served the moment it lapses: no grace window, no cached afterlife on our side. Deleting your account removes your tales with it, at once.
03Accounts and keys
A key is shown once, at the moment you mint it, then kept as a SHA-256 hash. We cannot recover it, display it again, or lose it in a database dump.
Passwords are hashed with scrypt, a memory-hard algorithm built to make bulk cracking expensive, and every new password is screened against known breach corpora, k-anonymised, so the password itself never leaves our server.
Add an authenticator code (with backup codes, and a lockout that makes guessing six digits useless) or sign in with a passkey instead. Trusting a device is opt-in, per sign-in, and expires.
Password-reset and sign-in links are single-use and short-lived (an hour for a reset, five minutes for a sign-in link), and requests are answered identically whether an account exists, so nobody can probe who is here. Every sensitive change is confirmed to your inbox.
Your account page lists every active session and can revoke each one; changing your password signs you out everywhere else. Deleting your account is self-serve and password-confirmed: account, sessions, keys and tales go together, at once.
Publishing, viewing, sign-in and key minting are all rate limited. Dashboard actions are origin-checked, so another site cannot act as you.
04Infrastructure
The service runs on Fly.io, and error logs never contain tale content. Failures are correlated by request id, never by body.
All traffic is forced to HTTPS, with HSTS telling browsers never to try anything else.
Every response (pages, API, assets) carries strict security headers. Tale pages load no analytics and set no cookies. The only script on them is our own, drawing the page’s charts.
Error logs never contain tale content: failures are correlated by request id, never by body.
Sub-processors, all five of them
05Found a hole?
Report vulnerabilities by email, or read the machine-readable version at /.well-known/security.txt.
[email protected]