Privacy

This page says what data this site touches, in plain terms. The short version: reading is anonymous, signing in is optional and passwordless, and the one feature that stores anything about you keys it to a one-way code we could not trace back to you if we tried. The email list is the exception, and only if you join it: it holds the address you type in, and it is described in full under Email updates below.

What this site does not do

• No advertising trackers, no ad networks, no social pixels.
• Google Analytics 4 runs on every page except the email preferences page. It is a Google service, it sets its own cookies, and what it collects is governed by Google rather than by this site. The counters described below are kept separately and do not depend on it.
• No account is needed to read anything here.
• Nothing is sold here, so there is no purchase data to hold.

Reading

The server keeps ordinary short-lived request records (address and path) in memory for rate limiting, and writes none of that to storage. What it does write is the visit counter described further down: running totals, and one row per browser holding a one-way hash and a date, with no address, no page address and no time of day in it. Pages set no cookies of this site's own. Google Analytics sets cookies of its own, described in the bullet above.

Signing in (optional)

Sign-in uses Google. When you choose it, Google confirms your identity and this site keeps exactly two things: your display name, and a one-way fingerprint computed from your email address. The address itself is never written to storage, never published, and never leaves the verification step. The fingerprint cannot be reversed into your address, but it is stable, which is what lets the same Google account see the same records on a later visit. Signing in never adds you to the email list, which is a separate feature you join only by typing an address into a subscribe form.

After sign-in, your browser holds a session token for up to 30 days. It lives in your browser, not in a server-side session store; signing out deletes it. There is no password anywhere in this design.

One honest consequence: because we do not keep your address, we cannot recover your records if you lose access to the Google account you signed in with.

The research log (signed-in users)

The research log stores the entries you create, keyed to your fingerprint, on this site's own storage. Log entries are private to you: they are never published, never shown to other users, and never used as editorial material. You can delete individual entries or the whole log from the page itself, and deletion is immediate and permanent. Free-text fields are screened against this site's own list of first-person human-use wording, held separately from the language rules the build enforces on published pages, and entries that match it are refused rather than stored.

Tips and responses

When you submit a tip or a response, the text you wrote, the handle you typed, an optional link, and (if you chose to sign in) your display name and verified marker are filed into this publication's private review system. Submissions enter the evidence pipeline described on the standards page; nothing is published without review.

The Report control at the foot of every article is the same intake with a different label, and it is worth saying exactly what one report holds. It stores what you wrote; the sentence you pasted into the optional box, if you used it, folded in above your note under a "Concerns:" lead so an administrator reads the quoted line first; the handle "Anonymous", because the Report form asks for none, or your Google display name if you signed in; the contact you gave, if you gave one; whether you asked for the article to be taken down; the time it arrived; and, if you signed in, that you did, with the same one-way fingerprint described above. It also names the article, because a report is about one page. It goes to this site's own intake, the same queue every tip and response reaches. When that channel does not take it, for any reason, a report is appended instead to a file on this site's own storage rather than being dropped, which is done for reports and for nothing else, because a takedown request that vanishes is the one submission this site cannot afford to lose. Filing a report also fires a notification to the site's administrators, and that notification carries neither the article's name nor any of your text: it says only that a report, or a takedown request, was filed.

Where things run

This site is hosted on Railway in the United States. There are no advertising trackers, no third-party analytics service, and no advertising anywhere on it. The counters this site keeps for itself are the next three paragraphs.

Three counters exist and they are worth describing exactly, because a counter is the sort of thing a reader is entitled to hear about from us rather than discover. The first is the click counter. When you click a vendor name, the link passes through this site so the click can be counted, and then sends you on. What gets stored is a single running total per vendor, and nothing else: no cookie is set, your address is not written down, no timestamp is kept, and no record of any kind is attached to you. The file behind it is a list of vendor names and numbers, so it can say that a vendor has been clicked forty times and can never say who did the clicking. Your browser sends no referrer to the vendor, so nothing about you or the page you came from is passed along. Where a link is marked REFERRAL LINK, the address carries a code that tells that supplier the visit came from Terminus, which is how the referral is credited; it identifies this publication, never you.

A second counter works the same way, and it earns the same description. The search box on the home page and on the ledger keeps one running total per query: the text someone typed, reduced to lower case letters, numbers, dots and hyphens and cut to 64 characters, and the number of times that exact text has been searched. One other thing sits beside that total, and it is a fact about the ledger rather than about anyone who searched: a true-or-false marker saying whether the query matched a vendor this publication already carries. No cookie is set, your address is not written down, no timestamp is kept, and no record of any kind is attached to you, so the file can say that a name has been searched forty times and can never say who searched it. Searches are never published, on this site or anywhere else: what a visitor types about a named business is their sentence and not this publication's, and no page here repeats it back in its own copy. A search that matches nothing on the page is handed to the vendor check through the address bar; with scripting on the handoff carries only the reduced form described above, in a fragment your browser does not transmit to this server, and with scripting off the form submits what you typed as part of the page address. The list is read privately, to see which suppliers people arrive looking for and do not find.

The third is the visit counter, and it goes one step further than the other two, so it is described in full. The footer of every page says how many visits this site has had and how many different browsers those visits came from. Telling browsers apart needs something that stays put, so your browser makes a random identifier once and keeps it in its own storage under the name terminus_visitor. It is a persistent identifier, which neither counter above uses, and it is here because the number of different browsers cannot be counted without one. No cookie is set, so it rides only in the one small message that records a page view, and never on any other request. That one message carries the identifier and the page address together, because it is one message; the two are counted into separate places and the pair itself is never kept. The server does not write that identifier down. It writes a one-way hash of the identifier combined with a secret value this site holds and never sends anywhere, so what is stored cannot be read backwards into the identifiers browsers hold. What is stored is two files: running totals, one for the site and one for each page address, and a list with one line per browser holding that hash and the UTC date the browser was first seen. Your address is not written down, no time of day is kept against a visit, and no page address is ever attached to a browser. The two totals in the footer are the only part of it anyone sees. Clearing this site's data in your browser deletes the identifier, and the visit after that counts as a new browser. One last thing, because a number printed on a page reads as a fact: these totals are what this site counted and nothing more. Anyone who can load a page can send the message that records a visit, and every reader with scripting off sends none, so the two figures are a rough measure rather than an audited one.

Google is the one exception, and it is worth stating precisely. Pages that offer sign-in, meaning the research log and the pages carrying a tip form, load Google's sign-in script when the page opens, not when you click. Google therefore sees your address and the page you were on, whether or not you go on to sign in. If you do sign in, Google also confirms your identity to this site. Pages with no sign-in option load nothing from Google at all. The only other outside party is your browser's own push service, and only if you switch notifications on; the section on browser notifications below sets out what it learns. The row of share buttons under an article is plain links and nothing more: no code from those platforms loads with the page, none of them is told you were here, and none of them hears anything at all unless you click one, at which point you are the one sending it. If you join the email list, Postmark, the service that delivers this site's email, receives your address and each message addressed to it, because delivering them is its job. Nobody else receives anything from this site.

Browser notifications

If you switch notifications on, your browser mints an address that this site can send a notification to, and hands it over. Stored beside that address are the time it arrived, how far your clock sits from UTC, the supplier records you have asked to be told about if you have asked about any, whether the subscription belongs to one of this site's administrators, and a note of the last article notification sent to it and when it went, so the same one is not sent to you twice. That is the whole row.

Sending one is not something this site can do by itself, and that is the part worth reading. The address your browser minted belongs to a push service run by whoever makes your browser: Google for Chrome, Apple for Safari, Mozilla for Firefox. To reach you, this site makes a signed request to that service naming that address, and the service wakes this site's code inside your browser, which then puts the wording together on your device. So your browser's push service learns that this site sent something to your subscription, and when. It is not told what the notification says, and nothing else about you travels with the request. There is no way to send a browser notification without a push service in the middle. If that is not a trade you want to make, leave notifications off; nothing else here depends on them.

The clock offset is there for one reason: an article is announced once, at around midday, and the offset is what works out when your midday is. It is a number of minutes rather than a place name, and this site never looks it up against a list of places. It does sit in the same row as everything above, because that row is the one record kept here. What an offset gives away is a band of longitude, and how much that narrows you depends on the band. There are 37 offsets in use in the world today. Fifteen of them belong to only one or two countries, so for those readers the offset is close to naming the country: UTC+05:45 is Nepal alone, UTC+03:30 is Iran alone. The most widely shared is UTC+02:00, used across 48 countries from Norway to South Africa, and even that rules out the Americas, most of Asia and all of Oceania. Counting countries also flatters the wide ones: UTC-04:00 looks broad at 32 countries, but most of those are small Caribbean islands, and in practice it means the eastern United States, eastern Canada or the Caribbean. So an offset is never a city and never an address, and it is never nothing either. Counts derived from the IANA time zone database on September 10, 2026.

Two limits on the midday promise, both worth saying plainly. Your browser only tells this site your offset when you load a page, so a subscription that has not seen a visit since this was built is sent to at midday in Denver, where the publication is, until your next visit corrects it. And a change to a supplier record you follow is sent when the change is noticed rather than at midday, because it is news about one business rather than an article. Your browser sends the offset again on a later visit, so it stays right if you travel or the clocks change.

Nothing beyond that row is kept. No name, no account, no address of yours, and no record of which notifications you opened or whether you opened any. The address your browser minted is held so a notification can be sent to it and for no other purpose, it is given to nobody except the push service that has to carry it, and switching notifications off in the panel on the front page deletes it here and at your browser in the same action. Your browser can also revoke permission on its own at any time, which stops the notifications whatever this site holds.

Email updates (only if you subscribe)

The email list is the one feature on this site that holds an email address, and it holds one only because you typed it into a subscribe form. For each subscriber it stores: the address, in lower case; the topics you picked; the supplier records you follow, if any; whether you want at most one email a day or one a week; whether you have confirmed; three random codes that make your confirm, preferences and unsubscribe links work; the date you signed up and the date you confirmed; which version of the consent wording the form showed you; which form you used (an article, a supplier record, the directory or the subscribe page); and delivery bookkeeping, meaning when a confirmation was sent, when the last confirmation email went out and the times of any sent in the last 14 days (at most three are sent in that time), the last day an email was considered for you, the day a digest that failed to send was given back for one more try, and a counter marking which items you have already been sent. If you are already subscribed and ask for a change, the change is also stored until you confirm it or it expires after 14 days: the topics, records and frequency you asked for, which form you used, a fourth random code for the link that confirms it, and when it was asked for and when its email was sent. It stores no IP address, no browser details, and no record of whether you opened an email or followed a link in one: open and link tracking are switched off at the sending service, and no email carries a tracking image.

Why it is kept: to send the emails you asked for, and for nothing else. Nothing is sent until you confirm from the email that arrives, and a signup that is never confirmed is deleted 14 days after its confirmation email goes out. Until the list launches, a signup waits unconfirmed and its confirmation email is sent once, at launch.

Who sees it: the list is never shared, sold or rented, and it is used for these emails only. Postmark, the service that delivers them, receives your address and each message addressed to it. Nobody else does.

Changing or deleting it: every email after you confirm links to your own preferences page, where you can change the topics, the frequency and the records you follow (the first email, which asks you to confirm, carries the confirm link instead), and every email, that first one included, carries a one-click unsubscribe. Unsubscribing deletes your record at once. What is kept afterwards is a one-way hash of the address, made with a random secret value, in a list of addresses not to email. It exists so that an address that unsubscribed is never emailed again unless somebody enters it on a form and it is then confirmed from that inbox, which removes the hash. Its limit, stated plainly: the secret value is kept on the same storage as the hash, so the hash keeps the address out of plain sight but would not stop someone holding that storage from testing a guessed address against it.

Questions and requests

For any question about this policy, or to ask for removal of something you submitted, use the contact route on the corrections page. This page changes only alongside the features it describes, and material changes are noted here with their dates.

Changes to this page

1 October 2026. An email list was added, so the section on Email updates is new, the opening paragraph now names it as the one place an address is held, the sign-in section says signing in does not join it, and the paragraph on outside parties names Postmark, which delivers the list's email. Recorded here under the same corrections policy as any other claim this publication makes about itself.

7 September 2026. A visit counter was added to the footer of every page. It is the first of the three counters described above to need something that stays with one browser between visits, so it has one: a random identifier your browser makes and holds, kept on this site only as a one-way hash. The paragraph above describes it in full, the sentence under Reading now says what the counter writes, and the line saying this site runs no analytics now says what it means, which is no advertising trackers and no third-party analytics service. This page describes the features it names and is not an inventory of everything this site stores. Recorded here rather than made quietly, under the same corrections policy as any other claim this publication makes about itself.

6 September 2026. The click-counter paragraph above used to end by saying the vendor is not told you came from here. That was true of what your browser sends, and it stopped being true of the whole address on the day the first referral arrangement went live: a link marked REFERRAL LINK carries a code in its address, and the code exists to tell that supplier the visit came from this publication. The sentence is now two, so it says both things separately. The referrer is still withheld, and the code names Terminus and never you. Corrected under the corrections policy, which applies to this publication's claims about itself exactly as it applies to a claim about a supplier.