Last updated: October 2026. Controller: threebodyorbits.com, info@threebodyorbits.com.
What is processed, and why
Serving the site. Cloudflare (the site, the orbit data files and copies of the files of the hunt survey’s published menu) sees your IP address and the pages you request, as any host does, keeps short-lived server logs, and may receive a network error report from your browser when a request to the site fails. Netlify answers the bare address threebodyorbits.com with a redirect to www.threebodyorbits.com, and so sees the IP address of visitors who use that address; it also runs the share links and print previews, which Cloudflare passes to it without your IP address. Legal basis: legitimate interest in delivering the site (Art. 6(1)(f) GDPR).
Analytics. GoatCounter counts page views without cookies or personal data.
Ratings and battles (atlas). A rating is stored with the orbit, the value and a salted one-way hash of your IP address so that each address counts once (the random identifier your browser keeps in local storage only lets you see and change your own rating); a head-to-head choice is stored only as the two orbits' updated scores. Both are kept in a database at Cloudflare (Western Europe), the host of the orbit data. Basis: legitimate interest in an honest leaderboard. Kept until you ask for deletion.
The hunt (atlas). Your browser keeps the paths it computed, any results waiting to upload and the checkpoints of a refinement in progress (the starting conditions of a loop being refined, its segment states and the count of steps taken, kept until the refinement is finished) in its IndexedDB, and your background-computing and cores settings in local storage, as well as, if your system asks for reduced motion and you choose to play the paths anyway, that choice (until you pause them again), and, if you dismiss a message from the site’s owner at the top of the hunt page, which message you dismissed (the time it was posted, or its text if it has none), so that it stays hidden and a new message still shows; a session token lives in page memory, and the tokens of the sessions that sent promising returns stay in the IndexedDB for two weeks (so that a loop you found can still be named after its path has left the notebook), and a path’s record notes when you declined to name its loop or put the invitation off for a day; the IndexedDB also keeps your device’s contributor token, its key, and its board name (the contributors’ board below); and the tab’s session storage notes which kernel build the page last reloaded itself for (so it never reloads in a loop) and, for a few minutes, that it was searching then (so it goes on after the reload). Each finished test sends the search's coordinator (our own server, hunt.threebodyorbits.com, which the page contacts directly) the starting conditions it was given and the numbers it measured (for a promising return also the page’s own first check of it, computed from loops the coordinator sends for comparison), nothing about you; while the coordinator offers it, a page with four cores or more that has searched for a while (the coordinator judges that from the tests the session already sent) may also be given a loop of the search to check at high precision (the deep check: its program is downloaded once, nothing is kept on your device), and it sends back the check’s numbers with how long it took, how many threads it used and its browser engine’s family (Chromium, Gecko or WebKit), kept with the session’s and contributor’s identifiers for two weeks; to give each loop to two different networks, and never to the network of the page that found it, the coordinator compares networks only in its memory, as keyed hashes of their address blocks (the last few of each session, forgotten when it restarts), and stores nothing of them; a name you suggest for a loop you found is stored with that loop and published only if approved, and if you decline to name it, the coordinator notes the time with that loop so it is not offered to you again; if you turn on notifications for the naming of your loops, your browser’s push subscription (a delivery address and encryption keys the browser makes, nothing about you) is stored by the coordinator until you turn them off, your browser withdraws it, or its delivery service reports it gone; the site’s owner’s own devices that receive the hunt’s alarms are kept the same way, registered by the owner from the review page, and hold nothing about visitors; the coordinator keeps a keyed one-way hash of your network address to limit how fast sessions can be opened, and also uses the address, in memory only and never stored, to tell whether two pages that report the same loop’s refinement as stalled are on one network (only pages on different networks count as two). When the search runs its newer protocol, your page also computes a 4-byte fingerprint of each test it runs and sends them with its results (the coordinator stores only a digest of them, and holds the few it draws for checking in memory), sends the family of your browser’s JavaScript engine (one of three words: v8, spidermonkey or jsc) and whether the page counts as light (a phone or tablet, the Light effort, or a slow device), runs the known reference orbits once at the start of a session to check your browser, and may be given a few tests, or part of the check of a loop, of another volunteer to compute again: numbers only, never who found them; the coordinator then keeps, per contributor, how many of its tests were checked and agreed or disagreed, any strikes, and which records it found or checked, and uses the keyed hash of your network address also, in memory only and never stored, so that your work is not checked by a page on your own network. No browser talks to another, and no visitor’s address is shown to anyone. For the contributors’ board the coordinator keeps, per contributor (a device that searched, or several that share its key), a random contributor identifier, a one-way hash of its token, a random number that picks its name from a fixed list of words (a new one when you press Shuffle, with the time of the last shuffle), the count of tests it completed (and of those beyond a plausible rate, which are not counted), when it was made and last opened a session, and which of its sessions belong to it; the board shows only those names, counts and ranks, nothing about you, and a contributor that completed no test is deleted 30 days after it was last seen. The page shows the token as “Your key”, so that you can copy it to another device (or a script of your own that runs the hunt): whoever holds it contributes under that name, and can rename it, so keep it to yourself. A key you paste from another device is sent only to the coordinator, which answers with its name and test count and stores nothing of the question (it counts the tries from your network, as a keyed hash of its address held in memory only and never stored, so that keys cannot be tried quickly); this device then keeps that key in place of its own. Clearing the notebook forgets the token on your device, and the next session starts a new name and count unless you use a copy of the key again. Basis: providing the search you chose to join. Kept until you clear the notebook (your device) or ask for deletion (the server).
The hunt’s survey (atlas; the hunt’s newer protocol, which runs on a share of devices once the site’s owner turns it on). A device that takes part builds its own tests from a session number the survey’s service on our server issues and from the published menu of kinds of test, and keeps in its IndexedDB a random device identifier (made once and never sent: it only decides whether this device takes part), the receipts not yet answered and, for every finished block of tests, one short record per test (a fingerprint of the test’s result, its count of force evaluations and what became of it), kept until the checks of that block are answered, and at most seven days; a promising return it found, or one it could not finish, is kept until the coordinator has accepted it; the rows of a census or section tile it computed are kept until the survey’s service has accepted them, and at most eight days; the tab that runs a session holds a lock on it in the browser (or, where the browser has none, a heartbeat in the IndexedDB), so that two tabs never send one session’s work; and in its local storage, for a session whose tab closed, the number of its next receipt and which of its unfinished blocks the closing tab sent, so that a later visit never sends them twice (removed once that session’s last work has gone). About every half minute (every few minutes when many pages search) the page sends the survey’s service on our server (hunt.threebodyorbits.com) a receipt: the session’s token, which carries your contributor identifier and never your key; a summary of each finished block (which kind of test, how many, their total work and outcomes, and for each promising return its braid word’s hash, masses, period and stability); the records it is asked for; and, when the tab closes, its unsent work. At the start of a session it also sends whether the page counts as light, the cores it uses, its measured speed, its browser engine’s family, the hashes of its code and the result of its start-up check. The service keeps every receipt with its arrival time and a daily keyed hash of your network: the address block you connect from (an IPv4 /24 or an IPv6 /48, never the full address) passed through a one-way function under a key made new each day (UTC), which is never backed up and is destroyed seven days after its day: once a day’s key is destroyed, nobody, the site’s owner included, can tell which network its hashes stood for. The promising returns the page sends on as finds (a loop’s starting state, period, masses, braid word and the proof its browser computed) and the rows of a census or section tile it computed go to the same service, which logs each with the session, your contributor identifier and that network hash. It is used to share the server’s checks fairly between networks, to cap what one network can add to the public counter, and to tell independent pages apart; the address itself is used only in memory, to limit how fast sessions are opened, as is how your connection was made (its HTTP version and whether it resumed an earlier one), which sets how often your page reports. The raw receipts stay on our server for about a day (26 hours) and a compact copy without the per-test records for 30 days in the site’s encrypted backup on Google Drive; what a check still needs is kept until that check has run, however long that takes. The survey’s own store (each session’s credit and network hash, what its checks still need, and a short record of each closed session for eight days) is copied into the same encrypted backup each night, more often during a surge, with the rest of the hunt’s data. Each session’s credit (confirmed, awaiting a check, or set aside and why) is kept with your contributor, and its pending tests are shown only to that contributor; the public board files hold names, confirmed test counts and verified finds, never an identifier or pending tests. A log of every test ever started is kept forever and deposited with each data release (on Zenodo and the orbit data host), so that anyone can regenerate and recheck every test: each session’s number, published only after the session has closed, and its blocks’ counts, kinds, menu versions and whether each was confirmed, with no contributor, name or network in it. Basis: providing the search you chose to join. Kept as stated, or until you ask for deletion of what is linked to your contributor.
Share links (generator). The orbit's parameters and rendered image are stored under a random identifier. Basis: providing the link you asked for. Kept until you ask for deletion.
Printing (generator). The artwork file is stored for the print partner and deleted after 90 days; your country, read from the request, selects the regional shop and is not stored. Zazzle handles the order under its own policy.
Your name and date of birth (generator) are processed in your browser only and never sent to us. The generator keeps your current orbit in session storage; the atlas keeps playback preferences in local storage. No cookies are set.
Your rights
You may request access to, correction or deletion of data relating to you, object to or restrict its processing, and complain to a data protection authority. Write to info@threebodyorbits.com with the share link or the rated orbit.