Cookie Policy

1. The headline

This website sets no cookies

Not one. No first-party cookies, no third-party cookies, no advertising identifiers, no analytics, no tracking pixels, no fingerprinting, no session recording. Nothing on this site loads from another domain: every stylesheet, script, image and font comes from our own server.

That would make for a short policy, except that the site does use one adjacent technology — your browser's local storage — and you are entitled to know exactly what goes in it. This document explains that in full, and also explains what would change if we ever did use cookies.

2. Cookies, local storage and the difference

The three technologies people usually group together behave quite differently, and the difference is the reason this site uses one of them and not the others.

	Cookies	Local storage	Session storage
Sent to the server?	Yes, on every request	Never	Never
Readable by the server?	Yes	No	No
Survives closing the tab?	Until expiry	Yes, indefinitely	No
Can be set by another domain?	Historically yes	No — strictly per-origin	No
Typical use	Sessions, tracking, advertising	Preferences, drafts, caches	One-visit state
Used on this site	No	Yes, four keys	No

The important line is the first one. A cookie travels to the server with every request, which is what makes it useful for tracking. Local storage never leaves your browser; nothing we run can read it remotely, and nor can anyone else's site.

3. Exactly what we store, and why

Four keys, all local, all first-party, all removable. Two are written the first time you visit; two are written only if you use a form.

Key	Contains	Written when	Purpose	Lifetime
`sm.theme`	The word `light` or `dark`	You use the theme switch, or the site records the system preference it followed	So the site opens in the reading mode you chose instead of flashing the wrong one	Until you clear site data
`sm.cookies`	The word `all` or `necessary`	You answer the storage notice	So the notice does not reappear on every page	Until you clear site data
`sm.lastEnquiry`	The values you typed into the contact or community form	You submit one of those forms	So the confirmation page can show you a copy of what you sent	Until you clear site data or submit again
`sm.subscriber`	The email address you entered	You submit the newsletter form	So the field can recognise that you already subscribed	Until you clear site data

None of these is transmitted anywhere. The site is static; there is no server-side process reading them, and no third party can see them because local storage is isolated per origin by the browser itself.

Every read and write is wrapped so that the site works normally when storage is unavailable — in a private window, with site data blocked, or where your browser is configured to refuse it. You lose the remembered theme and nothing else.

4. Why there is a notice at all

Legally, consent requirements attach to storing or accessing information on a user's device, not specifically to cookies. Strictly necessary storage is exempt; preferences arguably are too. We show a notice anyway, for two reasons.

You should know. Something is being written to your device. A one-line notice is more honest than relying on an exemption.
It demonstrates the contrast. Choosing “necessary only” genuinely changes what happens, which is not true of most banners you will have clicked through this week.

Choosing Necessary only means we record your answer to the notice and nothing else: no theme key is written, and the form keys are not written when you submit. Choosing Fine by me permits the four keys in section 3. Either way nothing is transmitted, and either way we are not tracking you — because there is no mechanism here that could.

5. How to inspect and remove it yourself

You do not have to take our word for any of this. Every modern browser will show you exactly what a site has stored.

Chrome, Edge, Brave: open developer tools (F12) → Application → Storage → Local Storage → this site. “Clear site data” removes everything.
Firefox: developer tools (F12) → Storage → Local Storage. Right-click an entry to delete it.
Safari: enable the Develop menu in Settings → Advanced, then Develop → Show Web Inspector → Storage. Or Settings → Privacy → Manage Website Data.
Any browser, quickest route: clear site data for this domain, or open the site in a private window, which starts empty and discards everything on close.

You can also confirm the negative: open the Network panel, reload the page, and check that every request goes to this domain and that no Set-Cookie header comes back. It is a reasonable thing to verify on any site that makes a claim like ours.

6. Blocking storage entirely

You are welcome to. The site is built to work without it.

Most browsers can block site data per-site in their privacy settings, or globally with an exception list.
Private or incognito windows discard all storage when closed.
Content blockers and privacy extensions can block local storage. They will find nothing to block here beyond the four keys above.
With JavaScript disabled entirely: all text, images, navigation and links work. You lose the theme switch, the search overlay, the filters, the accordions and the client-side form validation. The forms will still submit if you connect them to a server-side endpoint.

7. Third parties, and why there are none

Most cookie policies are long because most sites load code from many other companies. This one does not, deliberately. There is no:

Analytics platform of any kind, first- or third-party.
Advertising network, retargeting tag or conversion pixel.
Social media embed, share button that phones home, or comment widget.
Content delivery network. Every asset — CSS, JavaScript, images, icons — is served from this domain.
Hosted font service. The site uses fonts already installed on your device.
Video or audio embed, map embed, or hosted form service.
Tag manager, consent management platform, or session replay tool.

This has a practical benefit beyond privacy: the site loads quickly, works offline once cached, and cannot break because someone else's CDN had a bad afternoon.

Our servers do keep access logs, as described in section 3 of the privacy policy. That is server-side record keeping, not device storage, and it is not a cookie.

8. What would change if we added cookies

We have no plans to. If that changed — for example if we added member accounts to the community list, which genuinely needs a session cookie — we would:

Update this policy with the specific name, purpose, duration and provider of every cookie, before setting any of them.
Ask for consent before setting anything that is not strictly necessary, with refusing as easy as accepting and no pre-ticked boxes.
Set strictly necessary cookies with Secure, HttpOnly and an explicit SameSite attribute, scoped to the shortest workable lifetime.
Never use cookies for advertising, cross-site tracking or profiling. That is a commitment, not a current-state description.
Notify list members by email at least 30 days before the change took effect.

9. Changes and questions

We review this policy annually and whenever the site's storage behaviour changes. The version number and effective date at the top of the page always describe the current text.

If you find that this site stores something not listed in section 3, we would genuinely like to know — that would be a bug, and we will fix it and say so. Write to [email protected].

Related reading: the privacy policy covers everything we hold about you, and the terms of service cover the rest of your use of the site.