Privacy

What this site knows about you.

Short version: almost nothing, and nothing that points at you. The longer version is below, with enough detail to check rather than trust.

In plain language

The whole answer in five lines

No cookies. Nothing is stored on your device.
No accounts, and nothing that follows you to another website.
We count which pages get read and roughly how many people visit. We do not know which of those visits were yours.
Nothing you type into this site is kept.
No advertising company, analytics company, or data broker is involved.

That is the entire answer for most people. Everything below is for readers who would rather verify it than be told it.

For the technically minded

Exactly what is collected

One request per page view, to a path on this same domain, containing exactly these fields:

pathname, the page you loaded
referrer, the page that linked you here, if any
device_type, one of mobile, tablet, desktop
occurred_at, when it happened
signal_id, a random one-time value that names this message so a retry isn't counted as a second visit. A new one is generated for every request and nothing is kept, so two requests from you share nothing that could join them back together.

On the guide page only, the same beacon sends one more line per reply, recording whether the spoken voice was switched on and whether it actually produced sound: spoken, silent with a short reason, or not_requested. That exists because the voice was broken for weeks and nothing in our logs could distinguish "nobody turned it on" from "it failed", so it was fixed four times by guesswork. It carries none of your question, none of the reply, and nothing you typed.

There is no visitor ID, no session ID, no fingerprint, and no capture of anything you click or type. The one localStorage write this site makes is on the guide page and is not analytics: it remembers whether you asked for replies to be read aloud, so you don't have to press the button again on every visit. The source is one short file you can read in a minute: /beacon.js. It is served as a plain file rather than inlined so that the Content Security Policy can refuse inline scripts outright.

The request goes to this origin and is relayed onward by our own server, which attaches the credential. The key is therefore never in the page, and blocking the request is a supported outcome rather than something we route around: the path is not disguised, and an ad blocker that blocks it is behaving correctly.

The honest caveat

This is minimisation, not differential privacy

Differential privacy is a formal guarantee. It says that whether or not any one person is in a dataset changes the published result by at most a bounded amount, achieved by adding calibrated random noise to answers, with the strength of the guarantee stated as a parameter called epsilon. It protects the outputs you publish against someone reasoning backwards to an individual.

This site does something different and simpler. It minimises at collection: because no identifier is ever recorded, there is no row anywhere that is about you, and therefore nothing to re-identify from a per-person record.

Where that falls short.

Minimisation is not a formal guarantee, and we are not going to call it one. On a low-traffic site, an unusual referrer combined with an unusual page and a narrow time window could in principle single out one visit. We think that risk is small and we have not eliminated it. If we ever publish visitor statistics rather than just reading them, the right answer is noise added to counts with a stated epsilon and a per-period budget, and we would publish the epsilon alongside the numbers.

We would rather describe the property we actually have than borrow the name of a stronger one. A site arguing that automated decisions should be answerable does not get to be vague about its own.

Worth your attention

What to check, if you are checking

If you want to audit rather than read, these are the parts where a privacy claim on a site like this usually turns out to be false:

Third-party requests. Open the network panel. Every request should be to this domain, with one exception: the human check on the guide loads from Cloudflare, because a bot check served from the site it protects would not mean anything.
The Content Security Policy. Check the response headers. Inline script is refused rather than allowed, which is the difference between a policy and a decoration.
Where the analytics key lives. Search the page source for a credential. There is not one, because it is attached server-side on the way out.
Search. The index and its script are generated at build time and served from this domain. No query you type reaches anyone else.
Fonts and images. Self-hosted. No font CDN, which is a common quiet leak of visitor IP addresses.

One exception, disclosed

The guide, and your IP address

The guide is the one page that behaves differently, and it says so on itself before you use it. It makes a single, one-time use of your IP address to guess your general area, so it can suggest things happening near you. That guess is never stored and never logged, and you can simply type a different place instead. What you send it goes to a model in order to answer you, and the page lists in full what is sent and to whom.

The rest of the site is static HTML. Four pages run any script at all: the page-view beacon above, search, the guide, and the figure that moves while the guide is talking. Everything else renders without JavaScript, which is a consequence of building the site this way rather than a claim we want to make at you.