Cookies
Two cookies, and nothing to consent to
This site sets a session cookie and a CSRF token, and stores your light-or-dark choice in your own browser. It loads nothing from anybody else, so there is no banner: there is nothing here to ask you about.
No analytics, no tag manager, no pixels, no embedded video, no chat widget and no fonts from somebody else's server. A test fails the build if any of that changes.
The two cookies
Both are strictly necessary in the sense the ePrivacy Directive uses the words: the first carries the session that lets a form submission be matched to the person who filled it in, the second carries the token that stops a third-party page from submitting that form on your behalf. Neither identifies you to us across visits, and neither is read by anybody else.
The values below are read from this installation's own session configuration when the page renders, so they cannot describe a setting that is no longer in force.
The session. Encrypted, and on the public pages it holds nothing but the CSRF token and, after you submit the contact form, a one-request flash message.
- HttpOnly
- SameSite=Lax
- Secure
- Path=/
The cross-site request forgery token. Readable by the page's own JavaScript, which is the point: the form posts it back so the server can tell the two requests apart.
- SameSite=Lax
- Secure
- Path=/
The theme switch uses local storage
When you choose light or dark, the choice is written to `localStorage` under the key `ca-theme`. That is not a cookie and it is worth the distinction: local storage is never attached to a request, so the value never leaves your browser and this server never learns what you picked.
It exists because the alternative is a white flash on every page load for anybody whose machine says light and whose preference says dark. Clearing your site data removes it and the page falls back to what your operating system asks for.
localStorage · ca-theme
The things that are not here
Most cookie policies are long because most sites have a lot to declare. This one is short because the list of third-party origins this site contacts is empty, and that is enforced rather than asserted: `tests/Feature/Ui/MarketingSiteRendersTest.php` parses every URL in the rendered home page and fails if a host appears that is not this application.
The typefaces are served from this domain through the build pipeline for the same reason. A font request to somebody else's CDN is an IP address and a referrer handed to a third party on every page view, and no visitor has ever been asked about it.
| Analytics | None. No Google Analytics, no Plausible, no Fathom, no first-party analytics either. |
|---|---|
| Tag manager | None. |
| Advertising and pixels | None. No Meta pixel, no LinkedIn insight tag, no conversion tracking. |
| Fonts | Inter and JetBrains Mono, self-hosted and preloaded from this domain. |
| Embeds | No video player, no map, no chat widget, no social buttons. |
| Session replay | None. |
The control, and what it currently gates
The consent requirement in Article 5(3) of the ePrivacy Directive is about storing or reading information on your device. It carries an exemption for storage that is strictly necessary to provide the service you asked for, and a session cookie and a CSRF token are the textbook example of it. So on the strict reading, nothing here needs your permission today.
The control is on the page anyway, and it records a real answer rather than dismissing itself. Two reasons. A visitor who wants to refuse should not have to take our word that there is nothing to refuse; and a consent gate is far more likely to be honoured if it already exists and already remembers a choice than if it has to be retrofitted around a script that is already loading.
What that means concretely: your choice is stored on your device and in a first-party cookie, it is reachable again from the footer at any time, and refusal is the state until you choose otherwise. If anything non-essential is ever added — an analytics script, an embedded video, a chat widget — it loads only behind a positive choice, and this page is updated before it goes live rather than after.
What changes when you sign in
The console is a different surface with a different answer, and it is fair to state it here rather than leave it implied. Signing in uses the same session cookie, plus a long-lived "remember me" cookie if you ask for one, and the interface stores a small amount of layout state in your browser. All of it is necessary to operate the application and none of it is analytics.
There is no product analytics in the console either. Nothing measures which screens you open, and nobody watches a session replay of you working.
A route to a person, which is the point of publishing this
A DPA nobody can ask a question about is a PDF. If your review turns up something this page does not cover, or something it gets wrong, the form reaches the person who wrote it.
The other European documents
None of the seven documents in this set has been through a lawyer. They are engineering statements about a running system, published because a wrong description is worse than a missing one, and they will be reviewed before anybody is asked to sign anything.
Notes
-
1
Cookie names, lifetimes and flags are read at render time from
config/session.php, which is where this installation actually configures them. -
2
The no-third-party-origin assertion lives in
tests/Feature/Ui/MarketingSiteRendersTest.phpandtests/Feature/Ui/PublicSitePrivacyTest.php; both fail the build rather than the page.