›Cookies

The consent requirement in the ePrivacy Directive is triggered by storing information on, or reading information from, a visitor's device. That covers cookies, and it equally covers local storage, fingerprinting, and similar techniques whether or not the data is personal.

This site does none of those things, so the requirement is not engaged. A banner asking permission for storage that does not exist would be theatre, and it would train readers to click through consent prompts that do matter elsewhere.

Rather than asserted from the design intent, the claim is checked against the files that are actually published. In the build dated 2026-07-25:

• no shipped JavaScript file references document.cookie, localStorage, sessionStorage, or navigator.sendBeacon;
• no analytics or tag-manager globals are present, including gtag, dataLayer, and fbq;
• there are no third-party subresources at all: the typefaces are served from this site rather than from a font CDN, and the export ships no external scripts and no remote images;
• the only requests made after the page loads are to this site's own search index, and only on the search page.

You can confirm the first three yourself with your browser's developer tools: the Application panel will show an empty cookie jar and empty storage, and the Network panel will show every request going to this origin.

Serving a page still involves your IP address and request metadata reaching the host, Cloudflare. That is server-side processing rather than storage on your device, so it is outside the consent rule, but it is described on the privacy page rather than left unsaid.

Any future feature that stores something on your device, including a remembered preference, would require consent and would be described here before it ships. If you find this page contradicting what your browser reports, that is a bug worth reporting to Kartia IKE.