Privacy Policy

Who we are

The controller is Nikic Company (UK) Limited, operator of the taleseal service at taleseal.com. We are registered in England and Wales, company number 14073877, registered office 71-75 Shelton Street, Covent Garden, London WC2H 9JQ, VAT registration number GB416857080. We are registered with the Information Commissioner’s Office (ICO) as a data controller. You can reach us about anything in this policy at [email protected].

One important split: for personal data inside the content you publish (a tale’s contents, the name of the person it is written for), you are the controller: we store and serve that content on your instructions, as your processor, under the terms set out in the Terms of Service (section 18). For everything else this policy describes (your account, billing, run data operations, analytics), we are the controller.

What we collect

Account data. Your name, email address and password. The password is stored only as a scrypt hash. We never store it in plain text and cannot read it back.

API keys. Keys are stored only as SHA-256 hashes, together with the name you gave the key and timestamps of when it was created and last used. The key itself is shown to you once, at creation, and never stored.

Your content: tales. What you choose to publish. A tale may contain whatever you put in it (text, tables, code, images), and tales keep their version history until you retract. The CLI shows you a preview and warns you to redact secrets and anything sensitive before anything leaves your machine. If your content contains personal data, including the name of the person a tale is written for, that is data you chose to publish; section 9 covers your responsibilities and how anyone can report a problem.

Brand assets. If you set up branding, we store the colours you chose and any logo you upload, in our database, and serve it on your tales.

AI run data (telemetry). If you send us runs over OpenTelemetry, we store the raw spans of those runs: timings, model and tool names, token counts, error statuses, and the span attributes your tooling emits. This is what a published tale can draw its timeline and metrics from at render time. Span attributes are supplied by your own tooling and can contain whatever it put in them, so treat this as content you are publishing to us, and see section 7 for how long we keep it.

Billing data. If you subscribe, Stripe collects and processes your payment details (card number, billing address and any tax ID). Those never pass through us and we never store them. What we store is a Stripe customer reference on your account and your subscription’s status and dates. Stripe is an independent controller for the payment itself: see section 6.

Session data. When you sign in we set a session cookie (see section 5). The session record in our database also stores the IP address and browser user agent the session was created with, and is deleted when the session ends or expires.

IP addresses for rate limiting. Most rate limits (viewing pages, publishing, key minting) are counted in the application’s memory only: the address is held transiently for the duration of a short counting window, is never written to disk or to the database, and disappears when the window lapses or the app restarts. The exception is sign-in and sign-up, where the counter must survive restarts to keep password guessing slow: a counter keyed by network address is kept in our database, containing only that key, a request count and a timestamp, and is overwritten as windows pass.

Error logs. Minimal operational logs, correlated by request id. They never contain the body of your content.

Product analytics. We use PostHog (see section 6) to understand how the service is used, and it works in two ways. On our public pages — the marketing and documentation pages, and the sign-in and dashboard pages — we load PostHog in your browser to measure page views, clicks and session information. On the product itself — a tale being drafted, revised, published, viewed or retracted, an API key being created or revoked, a subscription starting or ending — we record a small, fixed set of events from our server, needing no cookie and no browser script. Every event carries only shape, never content: for a tale that means its size, block count and stationery, and never its id, title or body; for a subscription it means that one started or ended, never an amount or an address. Events by a signed-in user are linked to that account (by your user id, with your name and email held as account properties); anonymous activity is linked to no profile.

Advertising measurement. We advertise taleseal on Reddit. If you arrive from one of our Reddit ads, two things happen: Reddit’s measurement pixel loads in your browser, and we store the click identifier Reddit put in the link (rdt_cid) in a first-party cookie. If you then create an account, we tell Reddit from our server that a sign-up happened, sending only that click identifier, your taleseal user id as a de-duplication key, and your browser’s user agent. We never send Reddit your name, your email, or anything you publish.

Tale pages are never tracked in your browser. They load no analytics script, no advertising pixel, and set no cookie, signed in or not. Reading one is counted only by a server-side tally that knows the page’s shape, never who read it.

That is the list. Beyond the events above, we build no behavioural profiles and no device fingerprints, and we do not track you across other websites.

Why we use it, and the legal basis

• To provide the service: creating and authenticating your account, publishing and serving your content, storing your run data so your pages can draw on it, honouring expiry and retraction. Legal basis: performance of a contract (the Terms of Service).
• To take payment: managing your subscription and keeping the invoice records tax law requires. Legal basis: performance of a contract, and legal obligation for the records we must retain.
• To keep the service safe: rate limiting, abuse prevention, debugging failures via request-id-correlated logs, enforcing the Acceptable Use Policy. Legal basis: our legitimate interests in protecting the service and its users. None of this involves profiling or automated decisions with legal effects.
• Browser analytics and advertising measurement: the PostHog script and Reddit pixel on our public pages, and the ad-click cookie. Legal basis: our legitimate interests in understanding how the site is used and which ads bring people here.
• Server-side product events: the small, fixed, shape-only events described in section 2, recorded from our server with no cookie and no script. Legal basis: our legitimate interests in understanding whether the product works (which features are used, whether publishes succeed). You can object at any time by emailing [email protected] and we’ll exclude your account.

We do not use your data for marketing email, we do not sell it, and we do not share it with anyone except the recipients in section 6.

What we deliberately don't do

• No marketing emails: the only email the service sends is transactional, meaning account verification, password resets, email-change confirmations, sign-in links you asked for, and (if you subscribe) the payment emails Stripe sends about your card and invoices. There is no mailing list to be added to.
• No tracking on tale pages: they carry no third-party scripts at all, no pixel, no cookie. Analytics runs on our other public pages only; the pages you publish stay clean.
• No cross-site tracking by us: we build no profile of you across other websites. We do advertise on Reddit, and Reddit’s own pixel measures our ads; that is Reddit’s script under Reddit’s policy.
• No sale of personal data, ever.

Cookies

• Session cookie: strictly necessary, keeps you signed in (set by our authentication layer, Better Auth).
• Analytics cookies (PostHog) and advertising-measurement cookies (Reddit, including the rdt_cid click identifier): set on our public pages to see how the site is used and which ads bring people here.

Reading a tale sets no cookie at all, whether or not you are signed in. You can object to analytics at any time by emailing us (section 8).

Who else sees your data, and where it is processed

Our processors. These providers act on our behalf, under our instructions:

• Fly.io: application hosting. Holds traffic in transit and operational logs.
• Neon: the Postgres database. Holds accounts, key hashes, content, brand assets, run data and sessions.
• Doppler: secrets management. Holds our service credentials, not your personal data.
• PostHog: product analytics. Holds the analytics events in section 2, and for signed-in users your name and email as account properties. Data is stored in the EU. Never your content.
• Resend: transactional email delivery. Sees your email address and the account emails we send you (verification, password resets, sign-in links). Never your content.

Independent controllers. These are not our processors: they decide for themselves how they use what they collect, under their own privacy policies:

• Stripe, for payments. Stripe collects your card details, billing address and tax ID directly, and uses them for payment processing, fraud prevention and its own legal compliance. See stripe.com/privacy.
• Reddit, for advertising measurement, and only if you consent (section 2). Reddit receives the click identifier, your user id as a de-duplication key, and your user agent.

These providers run on global infrastructure and are US-headquartered, so your data may be stored or processed in the UK or elsewhere. Where processing involves a transfer outside the UK, it takes place under each provider’s data processing agreement, which incorporates recognised transfer safeguards (such as the UK International Data Transfer Addendum or Standard Contractual Clauses). Email [email protected] for a copy of the safeguards that apply to a given provider.

How long we keep it

• Tales: until you retract them, they expire, or you delete your account. Retraction destroys the content (body, title and every version) immediately and irreversibly; a tombstone row remains (the id and timestamps, but no content) so the address answers 410 Gone forever. Expiry stops the page being served from the moment it lapses. Account deletion removes the rows themselves (section 8).
• AI run data (raw spans): as long as a live page draws on them, plus a grace window. Your tales project their timeline and metrics from spans at render time, so spans behind a published page stay for as long as the page does. Spans that nothing points at (runs you never published, or whose pages have been retracted or have expired) are deleted 90 days after the run’s last span arrived, by the same hourly purge. Everything goes when your account goes, or on request.
• Brand assets: until you change or remove them, or delete your account.
• Account data: for as long as your account exists. When you delete your account (or we action a deletion request), your account, sessions, API keys, tales, brand assets and run data are removed. See section 8.
• Billing records: if you have ever paid us, we keep the invoice records (who bought what, when, and for how much) for six years after the end of the relevant tax year, because UK tax and VAT law requires it. This survives account deletion. It does not include card details, which we never had.
• Sessions: a session lasts up to 7 days, extended as you keep using the service; the record is removed when you sign out or it expires.
• Rate-limit counters: in-memory counters evaporate within minutes; the database-backed sign-in counters hold only a network-address key, a count and a timestamp, overwritten as windows pass.
• Backups: our providers retain database backups for a limited period (days, not months) before they age out, so recently deleted data may persist in a backup briefly.

Your rights

Under UK GDPR you have the right to access your personal data, to rectify it, to have it erased, to restrict or object to processing, to data portability, and to withdraw consent where we rely on it. You also have the right to complain to the Information Commissioner’s Office (ico.org.uk), though we’d appreciate the chance to sort things out first.

Your content can contain personal data: yours and other people's

You choose what a tale contains, and you must have the right to publish it: for personal data in your content, you are the controller and we process it on your instructions (section 1, and the Terms of Service section 18). A tale can be written to someone, and then it usually contains at least their name. Publishing it is your decision and your responsibility, and you should be confident they’d expect to receive it. Every published tale carries a link to this policy, so the person reading it can see how the page they’re on treats them: no cookies, no tracking, and a report route.

The Terms of Service and Acceptable Use Policy prohibit publishing other people’s personal data without permission. If a page contains personal data about you that you want gone: if you published it, retract it; if someone else did, email [email protected] with the URL and we will assess and act under our takedown process.

Security

Passwords are hashed with scrypt, API keys are stored only as SHA-256 hashes, card details never touch our servers, all traffic is forced to HTTPS, and error logs never contain the body of your content. The full, current list of security controls (kept in step with the code) is at /security.

Children

taleseal is not for children: the Terms of Service require you to be at least 18 to hold an account. We do not knowingly collect personal data from anyone under 18.

Changes to this policy

We may update this policy from time to time. When we do, we’ll post the new version here and update the “Last updated” date at the top. If a change is material, we’ll flag it prominently with reasonable notice before it takes effect.