Cookie Policy

• We use strictly necessary cookies only: the authentication cookies set by Supabase, which is the service that handles sign-in for us. They are the only cookies this site sets at all.
• 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.
• Signed out, you get nothing. The pre-launch password gate has been taken down, so the cookie that went with it is no longer set. Reading the site without signing in now leaves no cookie on your device. The only thing written anywhere is the one described in section 7, and only if you land on a page that does not exist.
• Block them and everything still works except staying signed in.

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. All of them are set by Supabase, our authentication and database provider, and none of them is set until you ask to sign in. 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 worth being straight about. 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 embedded maps, no social buttons, no fonts pulled from someone else’s server, and no video that loads before you ask for it. There are two exceptions, the security check on the sign-in page and the podcast video on some news articles, and rather than bury them we have given them the top of the next section.

Two pages load something from somebody else, one video player loads only when you press play, one thing runs on every page, and several links take you to somebody else. In each case their rules apply to what they do, not ours.

• The security check on the sign-in and contact pages: /login and /contact load 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 or flooding the contact form, and it is not decoration: Supabase refuses a sign-in that does not carry a token from it, and the contact form refuses a submission without one. 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 the contact page and nowhere else. What Cloudflare receives is also listed in the Privacy Policy.
• The podcast video on news articles: some roundups on /news have a short video version of our weekly podcast. Until you press play, it is a picture served from aisat.uk and nothing is requested from YouTube. Pressing play, next to a notice saying so, loads YouTube’s player from youtube-nocookie.com, its privacy-enhanced mode. From then on YouTube, run by Google, receives your IP address and may store information on your device on its own domain, under its own privacy policy. It sets nothing on aisat.uk. Pressing play is your choice to allow that; if you would rather not, do not press it, and the article and its spoken version work exactly the same without it.
• 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.
• The links in our footer: LinkedIn, our WhatsApp channel, our Discord server, our YouTube channel and our Spotify and Apple Podcasts shows are each run by somebody else, under their own privacy policies, and each sets its own cookies on its own domain once you are there. Following one sets nothing on aisat.uk, and none of them carries a referrer, so the site you land on is not told which of our pages you came from. Joining the Discord server shows your Discord username and what you post to the other members; 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.

One thing is kept there for a reader, and it is as small as it sounds: our “page not found” screen plays one of forty short films, and your browser remembers which one you saw last so the next one is a different film rather than the same one again. It is a number between one and forty. It says nothing about who you are, it is not read by anything else, and clearing your site data forgets it.

There is a second thing, and it never reaches a reader, but this page would be wrong to leave it out. When someone on our team is writing a newsletter in the admin area, their browser keeps a copy of the draft they are typing, so that a crashed tab or a failed save does not lose an afternoon’s work. It is written on their own device, it holds our unpublished words rather than anybody else’s data, and it is deleted the moment the draft is safely saved. Nobody who is not signing in to write a newsletter will ever have one.

The membership form does the same for you. If you start an application and do not finish it, the answers you have typed so far, which include your name, your employer and your LinkedIn address, are kept in your own browser so the form is still filled in when you come back. It is held against your account, it is never sent anywhere until you submit the form, and it is deleted when you do, and when you sign out. Clearing your site data forgets it.

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 stops it is a tool that blocks scripts: a content blocker, a privacy-focused browser, or a “do not track” extension. Nothing on the site behaves differently if you use one.

One caveat we would rather state than have you find. Vercel serves the measurement script from our own domain, under a path that changes rather than a fixed, recognisable one. That is their design and not a setting we chose, and its purpose is to be harder for blocklists to match, so a blocker that works from a list of known trackers may not catch it, while one that blocks scripts outright will. We are telling you because a page that says “you can block this” ought to say how easily.

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.

Content from another service that loads only when you ask for it, like the podcast video in section 6, asks at the point you use it instead: it is off until you choose it, refusing is simply not pressing play, and it is described in section 6 before you need it.

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.

“We” on this page is AISAT Events Ltd, which runs AISAT. Its company details are in the Privacy Policy.

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