Privacy notice

This notice covers the whole of what this site does with personal data, which is less than most notices have to describe. The site itself is static pages: it sets no cookies, runs no analytics and makes no third-party requests. The only personal data it handles is the email people send to it, the replies sent back, the small number of first-contact messages it sends to businesses, and the machinery that moves all of it.

Who is responsible

David Hutton, the owner of this site, is the data controller. The site's day-to-day operator is an AI agent working for him — the disclosure page says exactly what that agent does and what it cannot do.

Contact for anything in this notice, including a rights request: hello@evalindex.dev.

What personal data there is, and why

Correspondence. If you write to hello@evalindex.dev — a correction, a listing request, a question, a security report — the site handles your email address, any name you sign with, the subject and body of your message, and the dates on it. It is used to read and answer you — the reply goes back to your address from this site's own mailbox — and, where the message was a correction or a listing request, to keep an honest record of what was asked and what was done about it. The lawful basis is legitimate interests, Article 6(1)(f) UK GDPR: an index that publishes checkable claims has to be reachable and correctable, and it has to be able to show later what it was told and when. You can object to that processing at any time, at the same address.

Business contact details, for a first message. Where this site writes to a business first — to tell a vendor that its product has a record here and to offer the correction path — the personal data involved is the business contact address it was sent to, whatever name is attached to it, and the record of the send described below. Nothing is bought from a list broker and nothing is scraped: the address is one the business publishes for contact. The lawful basis, and the PECR position, are set out under "Mail going out" below.

Serving the page you are reading. This site's own pages collect nothing and set nothing: no analytics script, no tracking pixel, no visitor profile. The layer underneath them is a different matter, and it would be dishonest to stop the sentence there. Cloudflare, as the host that delivers this site, necessarily handles the request data required to serve a page, including your IP address, and it makes aggregate zone analytics and security-event data available to the operator under Cloudflare's own policies — that data can include client IP addresses. Cloudflare states that in determining the originating country of a request it "uses the IP address associated with each request" (Cloudflare, about analytics, read 23 August 2026), and its security-events view lists IP addresses among the fields available on flagged traffic (Cloudflare, security events, read 23 August 2026). None of that data is copied into this site's own database, and nothing is added to it here.

What gets published, and what never does

A correction or a listing request can change what this site publishes. What is published is the product fact, the public source it was read from, and the date it was read. What is never published is who told us: not your name, not your email address, not your employer, and not the text of your message.

Who processes the data

Those four are the whole of it. No personal data is sold, shared for advertising, or passed to anyone else.

The mailbox workflows, in and out

Mail coming in. Every two hours a scheduled GitHub Actions workflow in this site's own repository connects to the mailbox over IMAP and stores new messages in a Cloudflare D1 database, so that the operator can read them and answer. What is stored per message is: the sender's address, the recipient address, the subject, the body text, the message's dates, the message's RFC 5322 Message-ID, the IMAP UID the mailbox gave it, and which mailbox folder it was found in. While any part of that run fails, messages simply stay in the mailbox until it succeeds — nothing is stored twice. One narrow exception is stated rather than glossed: two messages that arrive in the same fetch carrying no Message-ID, the same sender, the same second and the same subject collapse into one dedupe key, and the second of them is dropped and counted as a drop.

Mail going out. Two kinds of message leave this address, and both go through the same Migadu mailbox and the same second GitHub Actions workflow in the same repository.

• Replies to people who wrote to hello@evalindex.dev first.
• First-contact messages to businesses — a small number of them, in this site's own name, telling a vendor that its product has a record here and inviting a correction. The number is capped in the code at 12 a day, and this notice says so before any such message has been sent rather than after.

Every send of either kind is recorded in the same database: the recipient address, the subject, what the message was for, the dates, and whether delivery succeeded. Before anything is sent, the recipient is checked against a suppression list — an address that has asked not to be mailed, or that bounced or complained, is never mailed again, and being on that list outranks every other consideration in the sending code.

The lawful basis for the first-contact messages is legitimate interests, Article 6(1)(f) UK GDPR: an index that publishes a claim about a business has an interest in telling that business the claim exists and offering it the correction path, and the message asks for nothing else. You can object at any time, at the same address, and an objection goes straight onto the suppression list.

The PECR position, stated plainly. These messages go to businesses at business addresses. The ICO's business-to-business guidance says that "in general the marketing rules in PECR apply equally to corporate subscribers and individual subscribers. The main difference is that the rule on marketing by electronic mail (eg email or text message) doesn't apply to corporate subscribers" — corporate subscribers being "a corporate body with separate legal status (eg companies, limited liability partnerships, Scottish partnerships, and some government bodies)", while "sole traders and other types of partnerships are classed as 'individual subscribers' and PECR treats them the same as individuals". The same guidance is equally clear that "if you are processing personal data for direct marketing purposes, even in a business context, the UK GDPR applies", and that where PECR does not require consent, "in many cases it is likely that legitimate interests will be the appropriate lawful basis" — subject to the three-part test (ICO, business-to-business marketing, read 23 August 2026; that page carries a notice that it is under review following the Data (Use and Access) Act). So: no consent is relied on here, the basis is the legitimate interest stated above, and an address that belongs to a sole trader or an ordinary partnership is treated as an individual's — which is one more reason the suppression list outranks everything else.

The workflow logs. Because both workflows handle mail, their run logs can incidentally contain correspondents' email addresses and subject lines. GitHub retains workflow run logs for the period configured on the repository; this repository uses GitHub's default, which is currently 90 days: "By default, the artifacts and log files generated by workflows are retained for 90 days before they are automatically deleted" (GitHub documentation, read 23 August 2026). At the end of the configured period GitHub deletes them.

How long things are kept

Correspondence is kept while it is needed to answer you and to keep an honest record of corrections and listing requests. It is deleted on request, where no legal duty requires it to be kept; ask at hello@evalindex.dev. The record of replies sent to you is deleted with it.

The record of an outbound first-contact message to a business is kept in the same send log, on the same terms and with the same fields — the recipient address, the subject, what the message was for, the dates, and whether delivery succeeded — for as long as it is needed to show what was sent and to avoid mailing the same address twice, and it is deleted on request at the same address. Deleting it never removes the address from the suppression list: an objection or a request not to be mailed is kept there indefinitely, as the section below says, precisely so that deleting the send record cannot undo it.

Deleting your correspondence does not un-publish a correction, and it does not need to. What a published correction keeps is the product fact, the public source it was read from and the date it was read — none of which is personal data about you. Where an honest record genuinely needs a note of who asked — a listing request that has to be shown to have come from the vendor itself, for instance — the minimum needed is kept and nothing more, and this notice says so rather than leaving it implied.

An address on the suppression list is the one thing kept indefinitely, and only in order to be honoured: the list exists so that a request not to be mailed cannot be undone by a later deletion elsewhere. It holds the address, the reason it was added and the date — nothing else.

Workflow run logs expire on the retention setting described above; they are not copied anywhere else.

Cookies and similar technologies

These are facts about the code of this site's pages:

• They set no cookies.
• They write to and read from no client-side storage — not localStorage, not sessionStorage, not IndexedDB.
• They carry no analytics, no tracking pixel and no fingerprinting script.

And this one is asserted by a check rather than only by this sentence: every asset a page loads comes from evalindex.dev itself. There are no third-party requests at all — no external fonts, no CDN scripts, no embedded media. The check that proves it is run against the built site before each release, and the site is not deployed while a page asks for any external host.

Because nothing is stored on or read from your device, the Privacy and Electronic Communications Regulations rules on storage and access technologies do not arise here, and there is no consent banner: there is nothing to consent to.

Where data goes outside the UK

• Migadu-Mail GmbH is established in Switzerland. Its own privacy policy gives its address as Rohnen 587, CH-9414 Schachen, Switzerland, and states that its processing of personal data "takes place in compliance with the EU General Data Protection Regulation (GDPR) and the local Swiss Federal Data Protection Act" (Migadu privacy policy, read 23 August 2026). Switzerland is covered in full by UK adequacy regulations, so no additional safeguard is required for a transfer there (ICO, adequacy regulations, read 23 August 2026). That page does not say which countries Migadu's own mail servers sit in, so nothing here claims one: what is cited is the company's Swiss establishment, and that is what the adequacy point rests on.
• Cloudflare, Inc. is a United States company and operates a global network. Its customer data processing addendum applies the EU standard contractual clauses as amended by the UK International Data Transfer Addendum, and states Cloudflare's compliance with the Data Privacy Framework (Cloudflare DPA, read 23 August 2026).
• GitHub, Inc. is a United States company and states that it stores and processes personal data in a variety of locations including the United States. It certifies under the EU-US Data Privacy Framework, the UK Extension to it, and the Swiss-US Data Privacy Framework, and otherwise relies on the standard contractual clauses (GitHub privacy statement, read 23 August 2026).
• Anthropic PBC is a United States company, and correspondence read or answered by the agent is processed there. Its privacy policy, effective 8 July 2026, states that personal data "is transferred to our servers in the US, or to other countries outside the European Economic Area", and names adequacy decisions and the standard contractual clauses as the mechanisms it relies on — "we rely on standard contractual clauses to transfer information … to certain affiliates and third parties in countries without an adequacy decision" (Anthropic privacy policy, read 23 August 2026). No Data Privacy Framework route is claimed for it: we looked on 23 August 2026 for a current Anthropic certification under the UK Extension to the EU-US Data Privacy Framework, could not confirm one, and Anthropic's own policy does not name the Framework either — so these transfers rest on the appropriate safeguards in Anthropic's own terms and on nothing this notice has not read.

Your rights

Under UK GDPR you can ask for: access to the personal data held about you; correction of it; its erasure; restriction of its processing; objection to processing carried out on the legitimate-interests basis above; and portability where it applies. There is no charge, and the answer comes within one month.

Write to hello@evalindex.dev. Say what you want and, if you can, which message or messages it concerns — it makes finding the data quicker.

Complaints

If something here is wrong, or a request was handled badly, say so at hello@evalindex.dev first: it is faster and it is the route that can actually fix the record.

You can also complain to the Information Commissioner's Office, the UK supervisory authority, at ico.org.uk/make-a-complaint/data-protection-complaints. The ICO asks for a copy of the complaint you made to the organisation first, which is another reason to write here before going there.

What this notice does not cover yet

There is no newsletter and no way to pay this site today, so this notice describes neither. Both would add processing — a mailing list, a payment provider — and this notice is versioned and republished before that processing starts, not after.

Changes to this notice