Cookie Policy

• We use strictly necessary cookies only: the pre-launch password cookie we set ourselves, and the authentication cookies set by Supabase, which is the service that handles sign-in for us.
• We use no advertising, marketing or tracking cookies, and no analytics cookie of any kind. The list of cookies in section 3 is the whole list, and counting visits did not add a row to it.
• We do count page views, using Vercel Web Analytics. It identifies a visit by a code worked out from the request itself, on the server, which is thrown away after 24 hours. Nothing is written to your device and nothing is read from it. Section 4 sets out exactly what is recorded.
• The password cookie is set for everyone while the gate is up, signed in or not, because getting past the gate is the thing it remembers. When the gate comes down it stops being set, and browsing without signing in will then store nothing on your device at all.
• Block them and everything still works except staying signed in. While the gate is up, you would also be asked for the password again on every page.

Cookies in the UK are governed by the Privacy and Electronic Communications Regulations (PECR), alongside the UK GDPR. PECR says you have to tell people about cookies and get their consent before setting them, with one exception. Consent is not required for a cookie that is strictly necessary to provide a service the user has explicitly requested.

A cookie that keeps you signed in after you have asked to sign in is the textbook example of that exemption, and a cookie that remembers you typed the password standing in front of the site is the same thing again: without it the site cannot do the one thing you just asked it to do. Every cookie in the table below is one of those, so there is nothing here for you to consent to, and a banner asking you to agree to something you cannot refuse would be theatre. We would rather explain it on a page like this one.

Counting visits is a different question, and it is worth being precise about why the answer is also no banner. What PECR regulates is storing information on, or gaining access to information stored in, your device. That is the act the rule turns on — not measurement, and not analytics as a category. Google Analytics would engage it, because it writes a cookie to your browser and reads it back on your next visit. The measurement described in section 4 does not: the code that stands in for a visitor is calculated on the server from the request that arrives there, and your device is never written to or interrogated. There is no stored information to consent to, so the rule that would have required a banner is not in play.

Every cookie below is a first-party cookie on the aisat.uk domain: no other site can read them. The first is ours. The other two are set by Supabase, our authentication and database provider. This is the complete list — measurement added nothing to it.

<project-ref> is the identifier of our Supabase project, so the real cookie name looks something like sb-abcdefghijklm-auth-token. Because the session data can be larger than a single cookie allows, your browser may show it split across numbered cookies such as sb-<project-ref>-auth-token.0 and sb-<project-ref>-auth-token.1. That is the same cookie in pieces, not extra tracking.

While a sign-in is actually in flight you may also see the verifier under two related names, sb-<project-ref>-auth-token-flow-<id>-code-verifier and sb-<project-ref>-auth-token-flows-code-verifier. Those are how the sign-in library keeps track of more than one attempt at once, for instance when you request a second link because the first one has not arrived. They are the same short-lived thing and they go the same way.

The attributes are not the same on all three, and the difference is worth being straight about. aisat_preview is ours, and we set it HttpOnly, SameSite=Lax and Secure in production, so no script can read it and it is never sent to another site. The Supabase sign-in cookies are SameSite=Lax and scoped to the whole site, but they are deliberately not HttpOnly: the sign-in code running in your own browser has to be able to read the session to refresh it before it expires, which is how you stay signed in. They do not carry the Secure attribute either, although the whole site is served over HTTPS and sends a strict-transport header, so in practice your browser has no plain-HTTP aisat.uk to send them to. What we do with the account behind them is covered in the Privacy Policy.

Since 31 August 2026 we count page views, using Vercel Web Analytics. Vercel is the company that hosts this site, so the measurement runs where the site already runs and the data does not travel to a fourth party. We wanted to know which pages are worth keeping and which are never read, and we did not want a banner or a tracking cookie to get it.

There is no cookie and no identifier stored in your browser. Instead a short code is worked out on the server from the request your browser sends, and that code is discarded after 24 hours. The practical effect is worth stating plainly: we can see that one person looked at four pages this afternoon, and we cannot tell tomorrow that it was the same person, or that they had ever been here before. The code cannot be used on any other website, so nobody can follow you from here to somewhere else.

Location is worked out from the network your request arrives on and can be as specific as a city. It is not a device location: nothing on this site asks your browser for GPS, and the permissions header we send blocks the geolocation API outright. Your IP address is used to work out the region and is not stored against the record.

Automated traffic is excluded. Vercel checks the user-agent a request announces itself with and does not count search-engine crawlers and other robots, so the figures are meant to be people rather than machines. That is a filter based on what a visitor claims to be, so it is honest about honest crawlers and would not catch something deliberately pretending to be a browser.

For the avoidance of doubt, aisat.uk does not set or allow any of the following:

• Google Analytics, or any other analytics product that sets a cookie, stores an identifier in your browser, or recognises you on a later visit;
• heatmap or session-recording tools, which replay what you clicked, typed and hovered over;
• advertising or retargeting cookies, including Meta, LinkedIn, Google Ads and TikTok pixels;
• cross-site tracking cookies, or fingerprinting meant to recognise you as you move between sites (the anti-bot check on the sign-in page does read signals from your browser, for the single purpose of deciding whether you are a person; it is set out in the next section);
• personalisation, recommendation or A/B testing cookies; or
• cookies that build a profile of you, whether for us or for anyone else.

We embed almost nothing belonging to anybody else: no YouTube players, no embedded maps, no social buttons, no fonts pulled from someone else’s server. There is one exception, on the sign-in page only, and rather than bury it we have given it the top of the next section.

One page loads something from somebody else, one thing runs on every page, and two places take you to somebody else. In each case their rules apply to what they do, not ours.

• The security check on the sign-in page: /login loads a script from challenges.cloudflare.com, which is Cloudflare Turnstile. It is what stops a bot asking us to email thousands of sign-in links, and it is not decoration: Supabase refuses a sign-in that does not carry a token from it. Loading the script tells Cloudflare your IP address, and the check looks at signals from your browser and device to decide whether you are a person. Cloudflare may set cookies of its own on its own domain as part of that; it sets nothing on aisat.uk. It loads when the page opens, before you type anything, and it runs on the sign-in page and nowhere else. What Cloudflare receives is also listed in the Privacy Policy.
• Vercel Web Analytics: a small script on every page reports that the page was viewed. Vercel already hosts this site and already handles every request to it, so this tells them nothing about you they did not see anyway. It sets no cookie and is described in full in section 4.
• Sign in with Google: choosing this sends you to Google to authenticate. Google sets its own cookies on its own domains, under its own privacy policy. If you would rather not involve Google, use the magic link option instead and no Google cookie is ever set.
• The WhatsApp community link: the invite we email to approved members opens WhatsApp, run by Meta, which processes your data under its own policies. Joining the group is entirely optional; see the Privacy Policy.

Cookies are not the only way a site can keep something on your device, so for completeness: we use the cookie-based Supabase client, which means your session lives in the cookie described above rather than in local storage. We do not store analytics identifiers, tracking values or personal data in local storage, session storage or IndexedDB. That is true of the measurement in section 4 as well — the code that stands in for a visit exists on the server for a day and is never written to your browser.

Your browser will still cache pages, images and fonts as it does for any site. That is ordinary browser behaviour, not tracking, and clearing your browser cache clears it.

You are in control of cookies in your own browser. Every major browser lets you see what is stored, delete individual cookies, block cookies from particular sites, or block them all. It is usually under Settings, then Privacy and security, then Cookies and site data; in Safari, under Settings, then Privacy. Most browsers also have a private or incognito mode that discards cookies when you close the window.

Because our measurement uses no cookie, blocking cookies will not stop it. What does stop it is any of the ordinary tools that block scripts: a content blocker, a privacy-focused browser, or a “do not track” extension. We would rather say that than pretend otherwise, and nothing on the site behaves differently if you use one.

The ICO publishes plain-English guidance on cookies for the public at ico.org.uk.

An earlier version of this page promised that if we ever added analytics we would say so here before switching it on, put non-essential cookies behind a consent banner, make refusing as easy as accepting, and list every new cookie in the table above. Section 4 is us keeping the first of those. The other three turned out to need nothing done, because what we chose sets no cookie at all — which is exactly why we chose it over Google Analytics.

The promise still stands for anything further. If we add something that stores information on your device or reads information from it, then before it is switched on we will:

• update this page and change the “last updated” date;
• introduce a consent banner, with non-essential cookies switched off by default and no pre-ticked boxes;
• make refusing as easy as accepting, and make it easy to change your mind later; and
• list every new cookie in the table above, with its purpose and duration.

We will update this policy whenever the cookies we set change. It sits alongside our Privacy Policy, which explains what we do with personal data more generally, and our Terms & Conditions.

Questions about anything on this page are welcome at privacy@aisat.uk.