What this site records

What is collected

Three things: a web server log, a summary counted from it, and a short message your browser sends once a page has loaded.

The web server log

Every request to this site is written to an access log kept for 30 days. Each line records the date and time, the HTTP method, the address you asked for, the response status and size, the referring URL, your browser's User-Agent string, whether our cache answered, and how long the response took.

⚠ Your IP address is not written to this log. The field where a web server normally writes it contains a literal -. This is not truncation or hashing: the address reaches the server, is used to route the response back to you, and is not recorded.

One field is derived from your address without storing it: a marker saying whether the request came from one of our own machines, so we can keep our own automated traffic out of the numbers. It records that fact and nothing else.

⚠⚠ The error log is the exception, and we would rather tell you than let you discover it. When a request fails — a broken link, a timeout, a server error — the web server writes a separate error log line that does contain your IP address. That cannot be prevented: the error log's format is fixed by the web server, so unlike the access log there is no field to leave empty. It is removed afterwards instead. A job on the server blanks the field that carries it — in the live log and in the rotated copies — once an hour, leaving a literal - where the address was. A deployment that reconfigures the web server blanks it again and then checks, failing rather than finishing if a line still carries an address there; that same step installs the hourly job, which then runs whether or not anything is deployed. ⚠ So there is a window, and it is up to about an hour: an address written just after a run stays until the next one. The line is kept for the same 30 days as the access log; the address in it is not. It is not read for analytics, nothing is derived from it, and it never reaches the database described below.

⚠ Some addresses are reduced before anything is written. Requests made by the loot tool itself — pushing, fetching, granting — are recorded as the shape of the address rather than its contents, so the log does not accumulate a list of the repositories stored here or the paths of files inside them. The same applies to every private-repository page.

⚠ Browsing a PUBLIC repository is not reduced, and that is deliberate rather than an oversight: those addresses are already public, and they are how we can tell whether anyone reads what is published here. So a request for a public repository's file is logged with its owner, its repository name and the file path — the same address that appears in your browser's bar. Ordinary pages, like documentation, are likewise recorded as they are.

A summary database

Once an hour those log lines are parsed into a database so they can be counted. It keeps the same facts with two reductions: the referring URL is reduced to its host, and the User-Agent is replaced by a coarse category — roughly "a bot", "our own automation", or "no reason to think otherwise". The User-Agent string itself is never stored in the database.

A message from your browser

Once a page has finished loading, your browser sends us one short message saying which page it was and which site you came from, if any. It exists for one reason: the log above cannot tell how many people visited, only how many requests arrived — and most of this site is served from a cache or as a pre-built file, so for many pages the log barely sees you at all.

That message records the page address, the referring site's host only, the coarse device, browser and operating system described below, and the day-scoped visitor key explained under Does this identify you? — which is the part worth reading.

⚠ Nothing is stored on your device to make this work. No cookie, no local storage, no identifier held in your browser between pages. If you have told us not to count you, your browser does not send the message at all.

What is not collected

• No IP address in the access log or the database — the error log is the exception named above, where the address is written and then removed rather than never written.
• No analytics cookies. Nothing on this site sets a cookie to count you. (Signing in is different — see below.)
• No third-party analytics, no advertising networks, no social widgets.
• No fingerprinting script, no screen size, no location or country. We do record a coarse device class, browser family and operating system — "mobile / Firefox / Linux" and nothing narrower — worked out from the User-Agent your browser sends anyway. No version numbers, no device model.
• No profile of you across visits, and nothing that follows you to other sites. What links a visitor's requests to each other lasts a day; what links a signed-in account's actions lasts as long as you want it to. Both are described below.

Does this identify you?

We do not think so, and we do not try to — but there are two identifiers, one for visitors and one for signed-in accounts, and this page would be wrong not to lead with them. The visitor one is described here; the account one is under If you have an account.

The visitor key. When a page finishes loading, your browser tells us which page it was. To count people rather than page loads, we need to know that two of those messages came from the same browser. So we take your IP address, your User-Agent and a secret random number that we generate fresh each day, hash them together, and keep the first 16 bytes of the result. That key is what links your requests to each other.

The secret changes every day and the old one is destroyed. Once it is gone, yesterday's keys cannot be connected to today's, and they cannot be worked backwards to an address — there is nothing left to check a guess against. That is the whole reason this is built with a daily secret rather than a cookie: the link is real for a day and then it is genuinely gone. One consequence, stated plainly: if you read this site either side of midnight UTC, you are counted twice.

⚠ Your IP address and your full User-Agent go into that hash and are not stored. They are used in memory, at the moment the message arrives, and discarded. No column in the database holds either one.

⚠ We nevertheless avoid calling any of this anonymous. For the 30 days a log line exists it contains your browser's full User-Agent string, and an unusual one — an old build, a rare browser, a custom tool — is more distinctive than a common one. Saying "anonymous" would claim more than we can demonstrate, so we describe it instead.

Why, and on what basis

To see whether anything on this site is useful and whether it works: which pages get read, whether the install instructions get followed, whether the cache is doing its job, and whether responses are fast. The lawful basis is legitimate interests — running and improving a site we publish. We judge the intrusion to be low because for a visitor the only identifier is the day-scoped key above — nothing is stored on your device, nothing survives the night — and for a signed-in account the reference is one you already hold under the terms you accepted, deletable on request. None of it is combined with anything else or shared. That is why it is built this way rather than with a cookie banner.

How long it is kept

The logs — both the access log and the error log — are kept for 30 days and then deleted. That bound is enforced by age rather than by a file count, so a quiet period cannot quietly extend it. ⚠ In the error log it is the line that lasts that long and not the address: that is blanked once an hour, as described above.

The rows in the database are deleted after 30 days too. A job runs every day: it first adds each finished day to a set of permanent totals, and only once a day's totals are safely written does it delete that day's rows — and only once they are 30 days old. If the totals step ever fails, nothing is deleted until it succeeds; the rows wait rather than vanish.

What is kept forever is totals, and only ever one thing at a time. Requests per day per page. Requests per day per browser family. Requests per day per referring site. Never a combination — there is no table that could say how many Firefox users read a given page — and never anything per visitor: the daily totals count how many people visited, and how many read each documentation section, but not who, and not which pages any one person read. These totals carry no identifier of any kind, so there is nothing in them to find or delete.

⚠ Rows carrying a visitor key are deleted on that same 30-day schedule, and they go blind long before that: the daily secret they were derived from is destroyed the next day, so for the rest of their life they hold a 16-byte value that can no longer be tied to an address, to a browser, or to any key from another day.

⚠ Rows carrying an account code do not go blind that way — the code is stable by design — but they are on the same 30-day schedule, so what any account's actions can be linked to is at most the last 30 days. Sooner, if you ask: see If you have an account.

Objecting

You can tell this site not to count you. It records your choice in a single cookie that contains no identifier — the only cookie this site sets for anyone who is not signed in, and only if you ask for it.

Checking…

⚠ Be aware of what this cannot do, because we would rather say so than let you assume. It stops the message your browser sends: with the objection set, your browser does not send it, so no visitor key is ever derived for you and you are not counted as a person. It cannot suppress the web server's access log, which is written before the application sees your request at all. So objecting takes you out of the counting of people and leaves you in the counting of requests, which holds no identifier for you to be found by.

If you would rather not appear in the access log either, write to us at the address below and we will tell you honestly what is and is not possible.

Erasure

For the log and the summary counts there is nothing to erase and no way to erase it selectively: they carry no identifier, so we cannot find "your" rows, and neither can anyone else. That is a property of the design rather than a refusal. The logs age out within 30 days; the summary counts stay as described above.

⚠ Rows carrying a visitor key are the one case where "your rows" briefly means something, and it lasts less than a day. While today's secret still exists, your key could in principle be re-derived from your address and browser and the matching rows found — so if you want them gone, write to us the same day and say so. Once the secret is destroyed that is no longer possible for us or for anyone, which is the same fact that makes the rows harmless and makes them unerasable. Setting the objection above prevents the key from being created in the first place.

If you have an account on this site, that is different — it is a record about you, you can have it deleted, and deleting the account deletes that record. The counted actions described under If you have an account are separate and are deleted when you ask. Write to the address below for either. Trust & security describes what the forge stores for an account and who can read it.

If you turn on telemetry in the loot command line

The loot tool sends nothing unless you run loot telemetry on. Off — the default — means no connection at all: no request, no lookup of our name. This is a separate matter from visiting this website, and it is here because the reports arrive at this site.

If you turn it on, loot mints a telemetry id — 16 random bytes that live in your own config directory, never derived from your machine — and sends at most one report a day, after a command has finished, never delaying one. A report holds: the loot version, the build platform, a count of how many times each command ran, and two coarse buckets for how big the last repository was and how long it took to open. Never a path, a message, a name, an argument or a timestamp; commands that record an incident (burn, maroon) are counted as other. loot telemetry show prints exactly what would be sent, before you decide.

⚠ The telemetry id does link your reports together, for as long as it exists — that is what lets us tell ten installs run once from one install run ten times. loot telemetry off deletes it, so earlier reports can no longer be tied to your install by anything we can compute; turning it back on mints a new one. The rows are deleted after 30 days like every other row here, and what survives forever is totals per command per day with no id in them. Within those 30 days you can quote your id from loot telemetry show and ask us to delete its rows — you hold the key, so you do not need us to identify you first.

If you have an account

Signing in is a different matter from reading, and it is worth separating. Accounts are handled by Clerk, which sets its own session cookies in your browser so that you stay signed in. That is not analytics and it is not optional for a signed-in session, but it is a cookie and this page would be wrong not to say so.

⚠ Actions you take while signed in are counted with a reference to your account. When you use the private pages — listing your repositories, reading a file, managing members — each request is recorded with the route it used (never the repository or file it named), the result, and a fixed code derived from your account. That code is the same every time, so unlike the visitor key it does link your actions together for as long as it exists — and that is deliberate: it is what lets us delete every one of those rows when you ask. It is not your account id and cannot be turned back into it. Objecting, above, stops this counting too.

⚠ Those rows are deleted after 30 days like everything else, and sooner on request. Deleting your account does not delete them at once — that link is not built, and we would rather say so — so if you want them gone before they age out, write to the address below and we will remove every row carrying your code.

Who is responsible

This site is run by Connor Miller, as an individual rather than a company, from the United States. Decisions about what is collected and why are mine, and the contact address below reaches me.

Who else sees it

This site runs on a virtual server rented from Hostinger, which necessarily carries the traffic and can reach the machine. Clerk processes sign-in for accounts, and Cloudflare R2 stores published release artifacts and repository content. The analytics described on this page are processed entirely on that one server — the log is read there, the counting happens there, and none of it is sent anywhere else.

Your rights

You can ask what is held about you, ask for it to be corrected or deleted, and object to the processing described here. For the log-derived records the honest answer to most of those is in the erasure section below: for the log and the summary counts there is nothing keyed to you to find, and for the day-scoped visitor key there is a window of less than a day in which there is.

This site is run from the United States and has no establishment in the UK or the EU. If you are in the UK or the EU and you think your data has been handled wrongly, you can complain to your own national data protection authority — in the UK that is the Information Commissioner's Office, ico.org.uk. Raising it with me first is welcome but not required.

Contact

security@millerbyte.com — the same mailbox as the security disclosure route, monitored by one person.

If this notice and the site ever disagree, the notice is wrong and we want to know.