Chess Pretraining

Privacy policy

Last updated 1 August 2026

Chess Pretraining is a small research project run by Brendan Long. This page says exactly what it stores and what happens to it. It is short because the data footprint is small: no ads, nothing that follows you across sites, and for analytics a page counter that sets no cookie.

What we collect

Settings like replay speed live in your browser's local storage and are never sent to the server. The server writes ordinary request logs, which include IP addresses, and its rate limiters hold short-lived counts in memory, keyed mostly by IP address, for up to an hour (until the process restarts, in the worst case) — neither is written to the database or tied to your responses.

What it's for

Two things: running Chess Pretraining for you, and the research it exists for. The point of the project is to measure whether dense labeled practice improves chess perception, and how fast — so your responses will be analyzed in aggregate, and results based on that analysis may be published.

Sharing with other researchers

We may share response data with other researchers or publish it as a dataset. What that data contains:

It never contains usernames, email addresses, IP addresses, or password hashes. We do not sell or rent data to anyone, for research or otherwise.

Where the data lives

The app runs on Fly.io, storing a single SQLite database on a volume there, with encrypted backups replicated to Amazon S3 and DNS served by Amazon Route 53. Both the app and its backups are hosted in the United States; which region is an operational choice we may change. Fly.io and Amazon Web Services are the only companies that hold the database, and they hold it as infrastructure providers — they do not get it for their own use. The one thing outside that picture is the page counter below: a separate service, on its own servers in Finland and Germany, which never touches this database.

Page counts

Every page sends one request to GoatCounter, a hosted counter, so we can tell how many people arrive and which sites sent them. It sets no cookie and stores nothing in your browser. So that a reload isn't counted as a second person, it holds your IP address and browser string in memory for eight hours, paired with a random id; none of the three reaches its database, and nothing it keeps follows you to another site or back here tomorrow.

We build that request ourselves rather than loading GoatCounter's script, which is what lets us say exactly what is in it. What we send: which of our pages you opened, chosen from a fixed list of the pages that exist, and the width of your screen, plus a random number so that the request isn't served from a cache and a flag when the browser says it is automated, so bots can be counted apart from people. Never the address bar's contents — once you have answered a question it names that position, which is what makes it a link you can send someone, and it stays in your browser — and never the page's title. If you arrived from another site we send that site's address without the page, and nothing at all when you arrived from ours.

Your browser supplies the rest on its own: its user agent, its language, and your IP address, from which GoatCounter derives a browser, an operating system, a language and a country — plus a state or province if that country is the United States, Russia, or China. What it keeps is counts, one table per kind of detail: pages and referrers by the hour, everything else by the day. Each table records the page, so it can count Firefox visits to this one; no two details share a table, so it can't tell whether that Firefox visit came from Texas. GoatCounter's own privacy policy is the authority on all of that.

It never sees your answers, your rating, your account, or your session cookie; it only knows a page was loaded. Any tracker blocker stops it, and nothing about the app depends on it working.

Cookies

One cookie, the session token described above. No advertising or analytics cookies: there is no advertising, and the page counter sets nothing. If you clear it while playing as a guest, that guest record becomes unreachable for good — there is no other way to find it, which is the same property that keeps anyone else from finding it either. So delete it before you clear the cookie, not after: the button below erases the record while this browser can still point at it, and afterwards nobody, including you, can say which record it was. The same goes for letting the cookie expire on its own, which it does after a year of not playing. Downloading a copy has the same deadline.

Taking a copy

Settings → Your data downloads everything listed above that belongs to you: your rating and how many trials you've answered, the username and email if you made an account, and every answer with its timing, the position it was about, and a link to the game it came from. The JSON file is the whole of it; the CSV is the answers alone, one row each, for a spreadsheet. Held back are only the hash of your password — which exists precisely so that nobody, us included, holds the password — and internal bookkeeping, like database row ids, that says nothing about you.

Signing up is not a condition of any of that. The anonymous record at the top of this page is created by your first answer, not by registering, and it is downloadable from that moment on. If you never make an account, a copy is also the only thing that survives clearing your cookie — after that the record is unreachable, as described above.

What the button hands over is deliberately the same set the delete button erases, so this page is not the only description of what we hold: the file is one too, and it can't fall out of date.

Keeping and deleting data

A visit that answers nothing leaves nothing to keep — the record is created by your first answer, not your arrival. Expired sessions are deleted automatically; everything else is kept while the project runs.

You can delete it yourself, account or not: Settings → Your data. That erases your rating, every response you ever gave, every session you have open, and — if you have one — the account and the email on it. Out of the research data too, not just out of your view, and it is exactly the set the download hands you.

Holding the session is how you prove the record is yours, which is why the button is the main route: the optional email is never verified, so for most accounts there is no address a request could come from. An account is asked for its password as well, because a browser someone has walked away from still holds the session. A guest has no password to ask for and none is invented: this browser's cookie is the only handle on that record, for you and for us, so it has to be enough — otherwise the guest half of what we hold would have no delete button at all.

If you can't reach that button, email self@brendanlong.com from the address on the account and we'll do it by hand. If the account has no email, say so and we'll agree on a way for you to show it's yours — an account nobody can prove they own is also an account anyone could ask us to delete. A guest record is the one thing that route can't reach: nothing outside the browser holding it says which record it is.

Two honest caveats either way. Deleted rows persist in encrypted backups for up to 30 days before those expire. And anonymized data already shared with other researchers or included in published analysis can't be pulled back — though it never contained anything identifying you. Nothing else of yours stays behind: how hard the app thinks a position is comes from the engine's own analysis of it, never from anyone's answers, so deleting your answers leaves nothing they had fed into.

Children

This isn't intended for children under 13, and accounts shouldn't be created by them.

Changes

If what we collect or do with it changes, this page changes, with a new date at the top. The page is versioned in the project repository, so its history is public.

Contact

Questions, deletion requests, or anything else: self@brendanlong.com.