Privacy

In short

What we store: your account, or a guest account while you try making a newsletter without one, the newsletters you make and everything it takes to produce them, the newsletters you subscribe to and what was sent to you, the visits to our public pages, and any report of a mistake you send us. The complete list is at the end of this page.

What we do not store: no advertising profile, and no IP address from a visit to a public page. We never ask you for health, beliefs, politics, ethnicity, sex life or anything else the law calls a special category. No card and no payment details. Nothing is charged yet and no payment provider is connected.

We do not sell, rent or trade your address, and we do not buy addresses.

Who else gets any of it: the companies that do a job for us - the one that sends the mail, the one that holds the database, the ones whose models write the issues, and a few more. Each is named under Companies that process the data, with what it is given and where it is.

How long we keep it: a visit to a public page goes after 90 days, an address that never confirmed a subscription goes after 48 hours, and a guest account goes 30 days after it was last used. Everything else stays until you ask us to delete it.

Where to write: [email protected]. One address for a question, a request to see or delete what is held about you, or a complaint, and a person reads it.

When you read a public page

A public page is any page you can reach without signing in: this one, the front page, the list of newsletters, a newsletter of its own and the issues it has published.

No cookie on a public page. A visitor who has not signed in holds none, until they press Start or Start this newsletter to try making a newsletter (see When you make a newsletter).

No IP address from a visit to a public page. Two visitors are told apart within a day by a hash that is re-salted every day, so the same person cannot be followed from one day to the next. Hashed means run through a one-way sum: what comes out cannot be turned back into what went in.

No advertising network, no tracking pixel and no third-party script: the public pages load nothing from any other host at all.

What is written down is the visit itself: which page, when, which newsletter or issue it was about, the share link it arrived by, and the site the visitor came from.

The same visit is also sent to PostHog, the company that counts what people do with the service: the page, the site you came from, the label on the link you followed, your country (from the address, which is not kept), whether you use a phone, a tablet or a computer, and the name your browser gives itself, which usually tells the kind of browser, its version and the system it runs on. So is pressing a button, each turn of the chat beside the library, and each step of signing up. None of these carries your IP address or your email address.

A visitor who has not signed in is named in PostHog by an id made from that day's hash, so one day's visits can be joined up and the next day's cannot. If you make an account that day, from the same browser and connection, that day's id is joined to your account.

We hold that to see which pages bring readers. The ground in law is our legitimate interest in knowing that. It rests on that rather than on your consent because a visit is counted without cookies and without IP addresses, and a visitor who does not make an account or start a newsletter is never named.

If you press Start or Start this newsletter to try making a newsletter without an account, PostHog names you from then on by your guest account's id, and that day's id is joined to it, so the visit before the press counts as yours. When you make an account, the guest's id is joined to your account.

If you never make an account, PostHog keeps those events under the guest's id. That id names nobody, and neither your address nor anything you typed goes with it. Deleting the guest account after 30 days does not delete them from PostHog.

We send the events of a guest to see where starting a newsletter goes wrong. The ground in law is our legitimate interest in knowing that. The guest account's cookie is there for the newsletter you started, not for the counting.

If you make a share link for a newsletter or an issue, we store the link, which surface it was made for, and who made it when a signed-in reader did.

If you report a mistake in an issue, we keep the issue, the story you chose, what you wrote and when. Not your email address, not your account and not your IP address, whether or not you are signed in. What you wrote is mailed to the person who runs FocusHeron and listed on a page only the admin can open.

To stop one place sending too many reports, the server counts them for an hour by a hash of your IP address. That count is kept in the server's memory only, and never written down.

To stop one place asking the chat beside the library too many things in a day, the server counts them by a hash of your IP address. That count is kept in the server's memory only, and never written down.

We hold a report on our legitimate interest in correcting what we publish.

When you subscribe

You give an address and choose a newsletter, an hour, a weekday and a timezone.

Until you confirm on the confirmation page, that address is held apart from the accounts, with the newsletter, the hour, the timezone and the share link it arrived with, so an address nobody stood behind never becomes an account.

Once you have confirmed, we store the subscription: which newsletter, the hour and the weekday you chose, your timezone, whether it is running or paused, the secret in your unsubscribe link, and which share link and which page brought it.

We store the record of each delivery - which subscription, which issue, when it went out, which provider sent it, and what that provider reported back afterwards: delivered, bounced or complained - and which tips mails have gone to a subscription, and when.

To stop one place filling the subscribe form too many times in an hour, the server counts the requests by a hash of your IP address. That count is kept in the server's memory only, and never written down.

We hold the subscription on your consent, given by pressing a button on the confirmation page, and withdrawn by the unsubscribe link in any issue. Withdrawing stops what comes next; it does not undo what was already sent.

When you confirm a subscription, we ask whether FocusHeron may write to you beyond your newsletters, unless you have answered before. Either answer confirms the subscription. We keep your answer, the words you were shown, where and when you answered, and every later change, as proof of what you agreed to. We hold it on your consent. Every such mail has a link that takes your yes back.

When Resend tells us what became of a mail - delivered, bounced or marked as spam - we keep what it sent us, which includes your address.

If you mark an issue as spam, you are unsubscribed. If your address refuses our mail, your subscription is paused.

We hold the delivery records on our legitimate interest in running a service whose failures can be found and answered for.

Your address is given to Resend, the company that sends the mail. It is never shown to anybody else: a subscriber is never named on a newsletter page and their address is never shown.

When you create an account

Your account holds your name, your email address, a picture link if you add one, and whether the account is an admin. An admin is an account allowed to run the service.

A password, if you set one. It is stored hashed, never as you typed it, beside the sign-in method the account uses and the tokens that method needs. A token here is a long random string that stands in for something rather than saying it: a link that signs you in, or the secret in an unsubscribe link.

If you choose Continue with Google, Google tells us your name, your email address and an ID for your Google account. We keep none of the sign-in tokens Google sends, and not your picture. We put that name on your account exactly as if you had typed it on the sign-up page. We do not see your Google password.

Each sign-in: when it started, when it expires, the IP address it came from and the browser it used.

One-time links: a sign-in link or an address confirmation, which is a token and the address it was sent to. It stops working when it is used or when it expires.

Signing in sets one session cookie, and so does pressing Start or Start this newsletter without an account. An admin's sign-in also sets a second cookie, which marks the admin's own visits so they are left out of the counts. While an admin views the service as another account to help them, the admin's browser holds two more cookies for up to an hour. There are no others.

We hold the account to give you an account and sign you in, which is the service you asked us for. The ground in law is the contract between us. The sign-in records rest on our legitimate interest in running a service whose failures can be found.

If we block an account, the account keeps when it was blocked and our reason. While it is blocked, that address cannot sign in. We hold that on our legitimate interest in keeping the service from being misused.

One admin - the person who runs FocusHeron - can read the whole database. Every action they take on an account, a subscription, a delivery, a production run or a newsletter is written down with who took it and why, and those records are not deleted.

To help you, an admin can view the service as your account for up to an hour. Each time is recorded with the reason.

You see your own: your account, the newsletters you made, their briefs, their conversations and your subscriptions.

When you make a newsletter

You can start a newsletter before you have an account: press Try it now, answer the first question and press Start, or press Start this newsletter on a newsletter we suggest. Either press makes you a guest account. A guest account is an account with no name and no address of yours, made so the newsletter has someone to belong to while you answer.

The press also sets a session cookie in your browser. It is how we know the newsletter is yours, so the service you asked for needs it.

Like any sign-in, the guest session holds the IP address it came from and the browser it used. What you type in the interview is kept under the guest account, the same as for an account.

To stop one place starting too many newsletters in a day this way, the server counts the starts by a hash of your IP address. That count is kept in the server's memory only, and never written down.

When the interview has written what your newsletter will be about, we ask you to make an account to go on. The sign-in link we mail you from there carries a token that names the newsletter and the guest account and stops working after two hours. It does not carry your address or your answers. When you sign in, the newsletter and everything under it moves to your account.

A guest account is deleted 30 days after it was last used, with everything still under it: its sign-ins, its newsletter, the interview and what you typed. A newsletter that moved to your account is no longer under it, so it stays.

We hold the guest account and what is under it to make the newsletter you asked us to start. The ground in law is the contract between us, the same as for an account.

A newsletter you made: its name, its address on the site, its language, who may see it, your author blurb, and the strapline under the name.

Its brief - the standing instruction the writer works from - is kept as versions rather than overwritten, so what the writer was told at any moment can still be read.

Before a brief is saved, one model call reads it with the newsletter's name, to check that it does not target a person or pass itself off as a brand's own. A brief the check refuses, or cannot answer for, is not saved. It is written to the log on our own server, so a person can look at it. That log is emptied each time the service is updated.

Its schedule: how often it is produced, at what time, on which weekday, in which timezone.

If you put a newsletter of yours live yourself, we ask whether FocusHeron may write to you beyond your newsletters, unless you have answered before. Either answer puts it live. We keep your answer as we keep a subscriber's: the words on the button you pressed, where and when, and every later change. We hold it on your consent. Every such mail has a link that takes your yes back.

Its sources: which of the shared registry's sources it uses, at which tier, and every rating, promotion, demotion or ban, with the reason given. The registry is the one list of sources every newsletter draws on, kept by web address; a tier is how much weight your newsletter gives a source.

Its production runs, and for each run which sources were fetched and what came back from them.

Its issues: the subject, the text as it was sent, the entries behind that text, and which link each entry cites.

A note each time an issue of yours was rewritten to keep it in our own words: which passages were too much like the source's own words, how much, and what the rewrite cost.

The interview that started it and the conversations that steer it: every message you and the agent wrote, which starter you pressed, each change the agent proposed and whether you approved it, and which step the interview reached and when.

The record of each model call your newsletter caused: which model answered, how long it took, what it cost, and the provider session id, which is the name the model company gives one call so a charge can be matched to it. Not the prompt, and not the answer.

We hold all of it to research, write and produce the newsletter you asked for. The ground in law is the contract between us: the brief, the conversation, the sources, the runs and the issues are what producing it takes.

We do not use your brief or your conversation to train a model. What the companies whose models write the issues do with what reaches them is set by their own terms; see Companies that process the data below.

If you make it public, readers see what it publishes: its name, its strapline, the author name and blurb, the picture the author added, and the issues.

Before a newsletter you made can be read by anyone else, we look at it. We keep who approved it and when, and a copy of what was approved: the name, the strapline, your author blurb and picture, and which version of the brief. If we refuse it, we keep when, and the reason you read.

When you ask for that look, we mail the person who runs FocusHeron your name, your email address and the newsletter. When we decide, we mail you, with the reason if we refused.

A listing decision about a public newsletter is kept: the admin who took it, whether it was approved or rejected, and the reason in the words the author reads. We hold these decisions on our legitimate interest in being able to show later how a decision was made.

Companies that process the data

These are every company that is given anything, what each is given, and where it is. Each of them keeps its own copy of what it is given, under its own terms, and none of them may do anything with it but the job named here.

Resend, in the United States, sends every mail and reports back what became of it. It is given the address, the subject and the message. How long Resend keeps a message it has sent is not stated in their terms as of 2026-09-20.

Turso holds the database, on AWS in eu-west-1, Ireland. Everything in the inventory at the end of this page is stored there and nowhere else.

PostHog, in its European Union region, eu.i.posthog.com, counts what people do with the service: nineteen kinds of event. They are a visit to a public page, a press of the subscribe button, a turn of the chat beside the library, a newsletter the chat drafts when nothing fits, the start, the refusal and the end of signing up, a sign-in, a press of a share button, your answer about mail from FocusHeron, opening the page that starts a newsletter, starting a newsletter, each answer in its interview (which answer, never what you wrote), the end of the interview, a guest's newsletter moving to an account, the sources found for it, its sample issue being ready, a newsletter going live, and a change to who may read it. An event names an account id, a guest account's id or, for a visitor who has not signed in, an id that changes every day. It is never given your IP address or your email address, and any event with an @ anywhere in it is dropped before it is sent. How long PostHog keeps an event is not stated in their terms as of 2026-09-20.

Anthropic, in the United States, and OpenRouter, also in the United States, run the models that research and write the issues; OpenRouter passes the work on to whichever model provider it picks. They are given the newsletter's brief, what its sources published, and, during an interview, a steering conversation or the chat beside the library, what you wrote in it. What either of them keeps, for how long, and whether it is used to train anything is not stated in their terms as of 2026-09-20.

Brave, in the United States, runs the searches that find what an issue is built from. It is given the search text, which is built from the newsletter's brief, so what you wrote when you made it can shape what is searched for. Brave keeps a query for up to 90 days, and takes the position that it is a third party for that text rather than something acting on our instructions. Whether Brave trains on our queries is not stated in their terms as of 2026-09-20.

Cloudflare, in the United States, is the domain's registrar and nameservers, stands in front of the site, and routes mail sent to [email protected] on to the operator. It sees the requests the site answers. How long Cloudflare keeps a request log is not stated in their terms as of 2026-09-20.

Sentry, in its European Union region (ingest.de.sentry.io), holds the errors the service runs into: what went wrong, where in our own code it happened, which newsletter, subscription or page it was about, and, when you are signed in, your account id. It is never given your IP address, and email addresses are removed before anything is sent. We do not send it what you write: not a brief, not a conversation, not a report of a mistake. Three things you typed can still reach it. A newsletter's name is on some of its records. So is the website name of a source or a picture address you gave. And when sending something fails, the error we record can quote part of what was being sent. When a page fails in your browser, your browser tells us what broke and we pass that on to Sentry ourselves: Sentry loads nothing in your browser and sets no cookie.

Google, in the United States, signs you in if you choose "Continue with Google".

Google Workspace, run by Google, is where the operator's mail arrives. It is given the mail we send the person who runs FocusHeron: a request to look at a newsletter, with the author's name and email address, and a report of a mistake, with what the reader wrote. We have not checked where Google keeps it.

Hetzner rents us the server the public site runs on, in Helsinki, Finland. Until the public launch the service runs on a private machine that no visitor can reach.

Inngest runs the queue of background jobs, and is not a third party here: we run the Inngest server ourselves, on our own machine, so nothing about you is handed to Inngest the company.

Nobody else is given anything. We do not buy addresses, and we do not sell, rent or trade yours.

How long it is kept

Three things are deleted by a purge that runs once a day: a page visit older than 90 days; an address that was typed into a subscribe form and never confirmed - within about a day and an hour of its 48 hours being up, and every confirmation mail we sent to that address is deleted with it; and a guest account 30 days after it was last used, with everything still under it. A confirmation that was used is deleted a week after it was used, because by then it has become a subscription and that is where the fact lives.

Nothing else is deleted on a schedule. Your account, once you have made one, the newsletters you made, their briefs, conversations, runs and issues, your subscriptions, your answers to mail from FocusHeron and the delivery records stay until you ask us to delete them, or until the service stops. If you ask us to delete your data, we delete your account and your sign-ins, your subscriptions and the delivery records under them, the newsletters you made, and every answer to mail from FocusHeron given for your address. If your account was blocked, the block goes with it. The record of what an admin did, and why, is kept even then.

A newsletter you made comes down within seven days of your request. If other people read it, it is deleted only after we have taken those readers off it. Their accounts stay. Until then we cannot delete your account, and we tell you so.

A report of a mistake stays until the newsletter it is about is deleted. It holds nothing that says who sent it, so to have yours deleted, tell us the issue and what you wrote.

Ask and they go: write to [email protected]. Issues already mailed stay in the inboxes they were sent to, which we cannot reach.

A session expires by itself. A sign-in link and a confirmation link stop working the moment they are used, or when they expire, whichever comes first.

Your rights and contact

FocusHeron is run by Usenestor.com ApS, CVR 45225240, Søstien 1, 3460 Birkerød, Denmark. That company decides what is collected and why, which makes it the data controller for everything on this page.

You can ask to see what is held about you, to have it corrected, to have it deleted, to be given it in a file you can take somewhere else, to have us pause our use of it while something is in dispute, and to object to the uses that rest on our legitimate interest.

Where a use rests on your consent, you can withdraw it whenever you like. There are two: the newsletters we send you, which you leave with the unsubscribe link in any issue, and mail from FocusHeron itself, which you stop with the stop link in any such mail, or by writing to the contact address below. When you write, we record your no as your answer, with the date, and it stays your answer until you give a new one yourself. Withdrawing stops what comes next; it does not undo what was already sent.

Write to [email protected]. That one address is all of it: there is no separate privacy address. We answer within one month.

When you write to us about a rights claim or a complaint, we keep what you wrote, the page it was about and what we did. We hold that on our legitimate interest in answering a claim and in being able to show later what was done.

If you think we have this wrong, you can complain to Datatilsynet, the Danish Data Protection Agency, or to the supervisory authority of the country you live in.

A new version of this policy is published on this page, with its version number and date at the top. The version published here is the one that applies. We do not mail a notice when it changes.

What the service promises, what it costs and what it will not write are the terms, at /terms.

Everything that is stored

The rest of this page is the complete list, for a reader who wants every field. It is written table by table: a table is one kind of record, with one row for each thing of that kind - one row per account, one per subscription, one per issue.

Everything in this list is in one database, the one we run, and it is the whole of what we store ourselves. It is not the whole of what exists: each company under Companies that process the data keeps its own copy of what it is given, and that section says who they are and what each one gets.

Your account: your name, your email address, a picture link if you add one, whether the account is an admin, and, if the account was blocked, when and why.

A guest account, made when you press Start or Start this newsletter without an account: whether it is a guest, and when it was made and last changed. It holds no name and no address of yours, and it is deleted 30 days after it was last used.

A password, if you set one. It is stored hashed, never as you typed it, beside the sign-in method the account uses and the tokens that method needs.

Each sign-in: when it started, when it expires, the IP address it came from and the browser it used.

One-time links: a sign-in link or an address confirmation, which is a token and the address it was sent to. It stops working when it is used or when it expires.

An address waiting to confirm a subscription, with the newsletter, the hour, the timezone and the share link it arrived with. It is held apart from the accounts until the person confirms from the link in the mail, so an address nobody stood behind never becomes an account.

Your subscriptions: which newsletter, the hour and the weekday you chose, your timezone, whether it is running or paused, the secret in your unsubscribe link, and which share link and which page brought it.

The record of each delivery: which subscription, which issue, when it went out, which provider sent it, and what that provider reported back afterwards - delivered, bounced, complained - with what the provider sent us about it, which includes your address.

Which tips mails have gone to a subscription, and when.

Your answer to mail from FocusHeron itself: yes or no, the exact words you answered, their version, where and when, the subscription whose confirmation asked, if one did, the secret in its stop link, and every later answer.

A newsletter you made: its name, its address on the site, its language, who may see it, your author blurb, and the strapline under the name.

Its brief, kept as versions rather than overwritten, so what the writer was told at any moment can still be read.

Its schedule: how often it is produced, at what time, on which weekday, in which timezone.

Whether it may be read by anyone else: who approved it and when, a copy of what was approved (the name, the strapline, your author blurb and picture, and which version of the brief), when you last asked, and, if it was refused, when and the reason you read.

Its sources: which of the shared registry's sources it uses, at which tier, and every rating, promotion, demotion or ban, with the reason given.

Its production runs, and for each run which sources were fetched and what came back from them.

Its issues: the subject, the text as it was sent, the entries behind that text, and which link each entry cites.

A note each time an issue of yours was rewritten to keep it in our own words: which passages were too much like the source's own words, how much, and what the rewrite cost.

The interview that started it and the conversations that steer it: every message you and the agent wrote, which starter you pressed, each change the agent proposed and whether you approved it, and which step the interview reached and when.

The record of each model call your newsletter caused: which model answered, how long it took, what it cost, and the provider session id. Not the prompt, and not the answer.

Which ways of reading it subscribes to, and how each is set up for it.

What each night's research counted for it: how much each way of reading offered, how much was kept, and how much was used.

What we learned about researching it, and what we proposed learning, each with the reason and the evidence behind it.

The places its subject lives that we cannot read, in your own words, so we can tell you and go and build a way to read them.

What each issue measured about itself: its length, its mix, how much of it carried a checked quote or number.

Share links: one per newsletter or issue and the surface it was made for, and the reader who made it, when a reader did.

Page visits on the public pages: the path, the moment, which newsletter or issue, the share link the visit carried, and the host the visitor came from. No IP address is stored and no cookie is set.

A report of a mistake in an issue: the issue, the story chosen, what the reader wrote, and when. Nothing about who sent it.

A listing decision about a public newsletter: the admin who took it, whether it was approved or rejected, and the reason in the words the author reads.

An admin action: who took it, what it was taken on, why, and what it moved. We keep these so a decision taken on your account, your newsletter or your subscription can be shown afterwards.

A sponsor slot that has been sold: the sponsor name, the slot text, where it links, the window it runs in and what it was sold for. That is about the sponsor, not about you.