Every category of reader data the publication collects, how long it is stored, who it is shared with, and how a reader can request deletion.
The publication's privacy picture is a small one because the publication itself is small. There is no contact form, no newsletter, no analytics, no account system, no third-party widgets. The desk holds a single mailbox and the hosting provider holds server logs.
What follows names what is collected, what is not, where it is held, who sees it, and what the desk does when a reader asks for a copy or a deletion. Where the practice could be clearer, the writing picks the wording that is shorter and more honest.
The publication is small enough that the desk's data picture stays small. The breach-handling rule listed here is short for the same reason.
The desk relies on its hosting provider's own breach-notification practices. If the provider alerts the desk to an event, the desk reviews the practical impact on the publication and decides what readers should be told and when.
If a reader has previously written to the editorial inbox and the desk holds a contact for them, a notification goes out by email as soon as the practical picture is clear. The note names what was exposed, what was not, what the desk has done, and what the desk recommends the reader do next. If there is no contact on file, the desk publishes the same notice at the top of the breach-handling reading instead.
Once the immediate response is closed, the desk publishes a short post-incident note alongside the privacy reading. The note describes the timeline in plain terms, the root cause as the desk understands it, the fix that was applied, and any change to the third-party list. Earlier notes remain checkable against the date they were filed.
The publication is small enough that the data picture stays small. The categories below cover everything the desk actively collects.
| Category | What is stored | How long | Why |
|---|---|---|---|
| Notes sent to the editorial inbox | Whatever you include in your message | Reviewed then held in the inbox; deletion on request | Read, triage, and reply to the note |
| Server logs | IP address, user-agent, request path | Held for the period the hosting provider retains them by default | Security, debugging, abuse handling |
The publication does not collect payment data, government identifiers, biometric data, or any special-category data under data-protection law. The publication does not run third-party advertising trackers, does not embed third-party analytics that identify individual readers, and does not operate a newsletter, account system, or comment system. The site is read-only editorial content.
The data the publication stores is small, which means the rights list is short and the writing can act on every entry within a reasonable time.
All reader-rights requests go through the editorial inbox. The desk treats each request in turn. Turnaround depends on the kind of request and any third parties involved. Where a request involves a third party (for example, the removal of a republished quotation), the desk passes the request on the reader's behalf and replies when the third party responds.
The third parties below are every external service that touches reader data on the publication. The list is short on purpose.
The hosting provider serves the publication and its static assets. The provider sees traffic as HTTP requests and writes the server logs described in the table. The provider does not have access to any reader-submitted content.
The publication is hosted by a managed hosting provider. The provider serves the publication and the static assets, sees traffic as HTTP requests, and writes the server logs. The provider does not have access to any reader-submitted content.
The reading loads no third-party scripts beyond the font stylesheet. There is no advertising network code, no analytics tracker, and no embedded widget. The site sets no cookies and writes nothing to localStorage. The mobile menu's open/closed state lives in the DOM only and disappears with the document.
The publication does not set cookies and does not write to localStorage. The mobile menu state lives in the DOM only.
Beyond the font stylesheet, no third-party scripts load. There is no analytics tracker, no advertising network code, no embedded widget, no session cookie, and no persistent identifier stored in the reader's browser. The mobile menu's open/closed state is held in JavaScript memory for the lifetime of the menu interaction; it is not persisted.
Material changes to the data picture are footnoted at the bottom of the notice with the date, so an earlier read remains comparable with a later one.
This notice was last reviewed on 2026-07-13. The data picture is now narrower: the site no longer operates a contact form, newsletter, theme toggle, or analytics layer, and the listed retention periods and third-party list reflect only the hosting provider that serves the static site.
The publication is an editorial reference for an adult audience. The desk does not knowingly collect data from readers under the age of 16. Where the desk becomes aware that data has been submitted by a reader under 16, the data is deleted.
The desk treats the following as awareness: a reader-self-declaration in a note, a third-party report (parent, guardian, regulator), or evidence in the message content itself that the sender is under 16.
The desk deletes the submitted data, deletes any derivative records tied to the same identifier, and replies to the original notifier confirming the deletion. The desk does not retain a record of the deletion for longer than necessary to confirm the deletion has been processed.
Readers from any jurisdiction may exercise the rights listed above. The desk honours stronger reader-protection regimes where they apply.
The reader-rights list on this privacy notice (access, correction, deletion, withdrawal of consent, list of third parties) is honoured regardless of where the reader is based.
The hosting provider that serves the static site stores server logs at its own infrastructure locations. The desk does not store reader-submitted notes in any controlled database; messages are held in the editorial mailbox and deleted on request.