Cookie Policy
Last updated
This page is the full inventory: everything stored in your browser, and every third party a page contacts. Nothing here is used for tracking, profiling, or advertising, which is why you are not asked to dismiss a consent banner to read it. Page views are counted, and that measurement stores nothing in your browser and carries no identifier — the section below says exactly what it records.
On this page
Complete inventory
| Name | Category | Duration | Purpose |
|---|---|---|---|
sessionCookie | Strictly necessary | 7 days | Keeps you signed in. Holds a random token; the server stores only its SHA-256 hash, so the cookie value cannot be recovered from the database.httpOnly, SameSite=Lax |
sm-themelocalStorage | Preference | Until you clear site data | Remembers whether you chose the light or dark theme, across both the public pages and the signed-in app, so the choice survives a reload. Never transmitted to the server.Not a cookie — never sent with requests |
cookie-consentCookie | Strictly necessary | 12 months | Records a cookie-consent decision, if this deployment ever declares a category that needs one. It is currently never set, because there is nothing to consent to — it is listed so the inventory is complete rather than only describing today.Readable, SameSite=Lax — not a tracking value |
Third parties a page contacts
Storage is only half the question. This is every external service a page in this application talks to, so the inventory above is not a technically-true answer that omits the interesting part.
Cloudflare Turnstile
Sign-up and sign-in pages only
A privacy-preserving alternative to a CAPTCHA, used to keep automated sign-ups out. Loading it contacts challenges.cloudflare.com, which means Cloudflare receives your IP address as it would for any request. It is not used to track you across sites, and it runs nowhere else in the product.
Consent: Not required: anti-fraud protection of a service you asked for is a recognised exemption under the ePrivacy Directive.
How page views are counted
We count page views, because a business needs to know which pages are read. The measurement is built into this application rather than bought from an analytics vendor, and it is designed so that it cannot identify you:
- Nothing is stored in your browser. No analytics cookie, no localStorage value, no identifier of any kind is written or read.
- No visitor identity is created. Not a cookie, not a fingerprint, not a hash of your address and browser. There is nothing to link two page views into a person.
- The page is recorded as a pattern, not a URL. A scan you open is counted as
/scans/[id], never as the address containing the scan’s identifier. - The referring site is reduced to a hostname. If you arrive from a search engine we record
google.com— never the full referring URL, which can contain what you searched for. - Your address and browser are not stored. The address is used to rate-limit the endpoint and then discarded; the user agent is never read. Screen size is recorded only as one of three buckets: mobile, tablet, or desktop.
The honest consequence: this counts page views and cannot count unique visitors, because counting visitors would require exactly the identifier we refuse to create. We would rather have the smaller true number than the larger one that costs you a consent banner.
What is not set
There are no analytics or advertising cookies, no retargeting pixels, no session-replay or heatmap tooling, and no cross-site tracking identifiers. No third-party analytics service receives anything about your visit — the counting described above happens entirely on our own servers.
The one third-party script loaded anywhere in the product is the Turnstile anti-automation check on the sign-up and sign-in pages, listed above. There are no others: no embedded video players, no font CDNs, no chat widgets, no tag managers.
Because every cookie is strictly necessary, the only other stored item is a preference you set yourself, and the page counting stores nothing at all, there is no non-essential storage to consent to or opt out of. The consent mechanism is built and dormant; if this deployment ever declares a category that needs permission, a real banner appears and this page changes with it.
Controlling these
You can clear both at any time through your browser's site-data controls. Clearing the session cookie signs you out, which is the same effect as using Sign out. Clearing sm-theme returns the product to following your operating system's light or dark preference.
Blocking the session cookie entirely will prevent you from signing in, since there is no alternative session mechanism. For what is stored on the server side rather than in your browser, see the Privacy Policy.
Why there is no consent banner
This deployment sets one cookie — the session cookie above — and it is strictly necessary to keep you signed in. Under the ePrivacy Directive and the GDPR, strictly-necessary cookies do not require consent, so a banner asking permission for it would be asking for something not required, for a cookie that gets set regardless. That is consent theatre, and it teaches people to dismiss dialogs that never meant anything.
The consent mechanism exists nonetheless — categories, a stored decision, a preferences dialog, and server-side logging of each choice. It activates automatically if a deployment declares a non-essential category via CONSENT_CATEGORIES. When it does appear, “Accept all” and “Reject non-essential” are the same size and one click each: burying the reject option behind a preferences link is a dark pattern, and one this product would flag on somebody else’s site.
Consent decisions are logged server-side with a truncated IP prefix and no visitor identifier. A consent log detailed enough to identify individuals has turned a privacy control into its own tracking dataset.